Presented in OWASP Qatar Chapter Meeting - June 2013

1. Secure Management of Credentials
Zouheir Abdallah, CISA
Senior Risk Specialist – CS/QCERT

2. 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.

3. 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

4. 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

5. 6/30/2013 44
Managing User IDs

6. 6/30/2013 55
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”.

7. 6/30/2013 66
Managing User IDs

8. 6/30/2013 77
Managing Passwords

9. 6/30/2013 88
Managing Passwords
• In traditional authentication methods, the password and the
User ID provide basic authentication.

10. 6/30/2013 99
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.

11. 6/30/2013 1010
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.

12. 6/30/2013 1111
Managing Passwords ( Complexity)
• Make sure that the application clearly states the password rules
that are in violation of your password policy.

13. 6/30/2013 1212
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

14. 6/30/2013 1313
Storing Credentials

15. 6/30/2013 1414
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.

16. 6/30/2013 1515
Storing Credentials
• Credentials should NOT be stored in the database in a clear text
form.

17. 6/30/2013 1616
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

18. 6/30/2013 1717
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

19. 6/30/2013 1818
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.

20. 6/30/2013 1919
Storing Credentials (Salting)
• Rainbow tables are precalculated databases of all possible hash
values.
Password Hash
a……… abef013bae221221
aa…… cb1290abcd2231ae
. .
.. ..
… …
…. ….
zzzzzzzzzzzzzzz 10cb2ae46dfg7120

21. 6/30/2013 2020
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
….. …………………

22. 6/30/2013 2121
Storing Credentials (Salting)
• Salting makes it hard for the attacker to mass “de-hash” the
leaked passwords.

23. 6/30/2013 2222
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
….. …………………

24. 6/30/2013 2323
Storing Credentials (Salting)
• How to validate the credentials with the stored salted hash?

25. 6/30/2013 2424
Secure and Un-Secure Practices

26. 6/30/2013 2525
Secure & UnSecure Practices
• Never send the user his/her password, neither via email nor via
any other form of communication.

27. 6/30/2013 2626
Secure & UnSecure Practices
• Never send the user his/her password, neither via email nor via
any other form of communication.

28. 6/30/2013 2727
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.

29. 6/30/2013 2828
2-Factor Authentication

30. 6/30/2013 2929
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)

31. 6/30/2013 3030
2-Factor Authentication
• 2-FA OTP via Mobile Phone

32. 6/30/2013 3131
2-Factor Authentication
• 2-FA OTP via Security Token

33. 6/30/2013 3232
2-Factor Authentication
• 2-FA via Digital Certificate

34. 6/30/2013 3333
2-Factor Authentication
Case Study - Dropbox

35. 6/30/2013 3434
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.

36. 6/30/2013 3535
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)

37. 6/30/2013 3636
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.

38. 6/30/2013 3737
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……85@hotmail.com
would work on the account zuz.85@hotmail.com

39. 6/30/2013 3838
Case Study -
• Vulnerability

40. 6/30/2013 396/30/2013 39
Questions?
Visit us on www.QCERT.org