secure management of credentials - zouheir abdulla
DESCRIPTION
Presented in OWASP Qatar Chapter Meeting - June 2013TRANSCRIPT
Secure Management of Credentials
Zouheir Abdallah, CISA
Senior Risk Specialist – CS/QCERT
6/30/2013 1
Introduction
• Since the introduction of the e-Commerce Law Decree No. (16)
of 2010, web applications have been on the rise in Qatar. These
portals grant the users the ability to perform various electronic
transactions.
6/30/2013 2
Introduction
• It is the responsibility of the owners of these web applications to
safe guard the credentials that have been entrusted to them.
Failure to properly secure the credentials of their user base,
could lead to a huge loss on both the financial side and the
business reputation side.
http://money.cnn.com/2012/01/16/technology/zap
pos_hack/index.htm?iid=EL#TOP
6/30/2013 3
Outline
1. Managing User IDs
2. Managing Passwords
• Password Length
• Password Complexity
3. Storage of Credentials
• No Encryption
• Hashing
• Salting
4. Secure and Unsecure WebApp practices
• Sending Passwords via email
• One-Time Token via a URL
5. 2-Factor Authentication
6/30/2013 4 4
Managing User IDs
6/30/2013 5 5
Managing User IDs
• A User ID is a unique identifier.
• As a WebApp developer, make sure that the User IDs are case
insensitive and the User ID “Ahmad” is the same as “ahmad” or
“AHMAD”.
6/30/2013 6 6
Managing User IDs
6/30/2013 7 7
Managing Passwords
6/30/2013 8 8
Managing Passwords
• In traditional authentication methods, the password and the
User ID provide basic authentication.
6/30/2013 9 9
Managing Passwords ( Length)
• Ideally, the longer the password the better.
• The web application should set a minimum password length and
enforce it on the user upon password entry.
• Minimum length should be at least 8 characters long.
6/30/2013 10 10
Managing Passwords ( Complexity)
• A web application should enforce a certain password complexity
schema to prevent users from using easy to guess passwords.
• Allow the user to enter virtually any password and any
character.
6/30/2013 11 11
Managing Passwords ( Complexity)
• Make sure that the application clearly states the password rules
that are in violation of your password policy.
6/30/2013 12 12
Managing Passwords ( Complexity)
• Preferably the web application should have the functionality to
force the users to choose passwords that adhere to specific
criteria set by the developer, for example:
• 1 Upper Case Letter
• 1 Lower Case Letter
• 1 Number
• 1 Special Character
6/30/2013 13 13
Storing Credentials
6/30/2013 14 14
Storing Credentials
• Credentials are essential to authenticating the users and
granting them access to the application.
• So it is only logical to enforce controls on the storage of these
credentials to mitigate the risk associated with their leakage.
6/30/2013 15 15
Storing Credentials
• Credentials should NOT be stored in the database in a clear text
form.
6/30/2013 16 16
Storing Credentials
• Passwords should be hashed rather than encrypted.
• Hashing is a one way function, while encryption is a two way
function and passwords can be decrypted and exposed.
encrypt / decrypt
Password DB
Password
Hash function
DB
6/30/2013 17 17
Storing Credentials (Salting)
• Salts are stored in plain text in the database along with the
Username and the SaltedHashed Password.
• The purpose of salting is to prevent mass leakage of passwords
IF the database was leaked.
UserName Salt Hash Salted Password
Mohammad 134a209 24bcde31100baccde2efgaedbc24
Omar abde312 a01bc34aef33120bge234666adcff
Rayan a1345gb 4cba201ddeg27aegdac6324012ba
6/30/2013 18 18
Storing Credentials (Salting)
• Make sure that the passwords are salted before being hashed
and then stored in the database. Salting adds an additional
control to counter the mass leakage of passwords via rainbow
dictionary attacks.
6/30/2013 19 19
Storing Credentials (Salting)
• Rainbow tables are precalculated databases of all possible hash
values.
Password Hash
a……… abef013bae221221
aa…… cb1290abcd2231ae
. .
.. ..
… …
…. ….
zzzzzzzzzzzzzzz 10cb2ae46dfg7120
6/30/2013 20 20
Storing Credentials (Salting)
• Attackers use them to find the passwords by comparing the
hashes of pre-calculated passwords with the ones leaked.
Leaked Database RainBow Table (Precalculated Hashes)
Hash Password Hash
24bcde31100baccde2efgaedbc24 ….. …………………
a01bc34aef33120bge234666adcff hEll0Every1 bb27cd134ca4200bdef4728100aca
4cba201ddeg27aegdac6324012ba iLoveQatar a01bc34aef33120bge234666adcff
n0TTrue 345acbde236ab20dd01bc12f4f332
….. …………………
6/30/2013 21 21
Storing Credentials (Salting)
• Salting makes it hard for the attacker to mass “de-hash” the
leaked passwords.
6/30/2013 22 22
Storing Credentials (Salting)
Leaked Salted Database RainBow Table (Precalculated Hashes) + Salt = abde312
Salt Hash Password Hash
134a209 24bcde31100baccde2efgaedbc24 ….. …………………
abde312 a01bc34aef33120bge234666adcff hEll0Every1 bb27cd134ca4200bdef4728100aca
a1345gb 4cba201ddeg27aegdac6324012ba iLoveQatar a01bc34aef33120bge234666adcff
n0TTrue 345acbde236ab20dd01bc12f4f332
….. …………………
RainBow Table (Precalculated Hashes) + Salt = 134a209
Password Hash
….. …………………
hEll0Every1 bb27cd134ca4200bdef4728100aca
iLoveQatar acbde2431bdde567aed321004212
n0TTrue 24bcde31100baccde2efgaedbc24
….. …………………
RainBow Table (Precalculated Hashes) + Salt = a1345gb
Password Hash
….. …………………
hEll0Every1 4cba201ddeg27aegdac6324012ba
iLoveQatar fbcd200123adcbfgbge234666adcff
n0TTrue acbde2431bdde567aed321004212
….. …………………
6/30/2013 23 23
Storing Credentials (Salting)
• How to validate the credentials with the stored salted hash?
6/30/2013 24 24
Secure and Un-Secure Practices
6/30/2013 25 25
Secure & UnSecure Practices
• Never send the user his/her password, neither via email nor via
any other form of communication.
6/30/2013 26 26
Secure & UnSecure Practices
• Never send the user his/her password, neither via email nor via
any other form of communication.
6/30/2013 27 27
Secure & UnSecure Practices
• In case the user has forgotten his password and clicked on the “I
forgot my password”, send the user a One-Time token via a
URL to his inbox. Make sure that this token has an expiry time.
6/30/2013 28 28
2-Factor Authentication
6/30/2013 29 29
2-Factor Authentication
• 2-Factor Authentication requires an additional input to the
traditional username and password combination.
• By introducing the 2nd factor, the web application is further
authenticating the true identity of the user via something the
user knows (User ID, password, secret image..) and something
the user has (Digital certificate, security token, mobile phone)
6/30/2013 30 30
2-Factor Authentication
• 2-FA OTP via Mobile Phone
6/30/2013 31 31
2-Factor Authentication
• 2-FA OTP via Security Token
6/30/2013 32 32
2-Factor Authentication
• 2-FA via Digital Certificate
6/30/2013 33 33
2-Factor Authentication
Case Study - Dropbox
6/30/2013 34 34
Case Study -
• Case Study of Dropbox’s flawed implementation of 2-FA.
• Discovered and reported by Zouheir Abdallah on June 10th 2013
• Fixed by Dropbox’s security team on June 21st 2013.
• Received acknowledgment and thanks from Dropbox……………
and a t-shirt.
6/30/2013 35 35
Case Study -
• Vulnerability
2-FA could be disabled for any person given that the
attacker knows the username/password of the victim.
• Attack Vector
The emergency backup code that Dropbox generates
for the user to use in case his/her 2-FA method is lost
(Think lost mobile phone)
6/30/2013 36 36
Case Study -
• Vulnerability
As mentioned earlier, the emergency backup code is
flawed. The code of one account can be used on another
account that is similar to the victim’s account.
6/30/2013 37 37
Case Study -
• Vulnerability
Dropbox didn’t disclose what the vulnerability was, but
according to QCERT’s analysis, the emergency backup
generation tool is dropping the DOTs from its algorithm. So
the emergency backup code for zuz……[email protected]
would work on the account [email protected]
6/30/2013 38 38
Case Study -
• Vulnerability