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 bee...
6/30/2013 2
Introduction
• It is the responsibility of the owners of these web applications to
safe guard the credentials ...
6/30/2013 3
Outline
1. Managing User IDs
2. Managing Passwords
• Password Length
• Password Complexity
3. Storage of Crede...
6/30/2013 44
Managing User IDs
6/30/2013 55
Managing User IDs
• A User ID is a unique identifier.
• As a WebApp developer, make sure that the User IDs ar...
6/30/2013 66
Managing User IDs
6/30/2013 77
Managing Passwords
6/30/2013 88
Managing Passwords
• In traditional authentication methods, the password and the
User ID provide basic authen...
6/30/2013 99
Managing Passwords ( Length)
• Ideally, the longer the password the better.
• The web application should set ...
6/30/2013 1010
Managing Passwords ( Complexity)
• A web application should enforce a certain password complexity
schema to...
6/30/2013 1111
Managing Passwords ( Complexity)
• Make sure that the application clearly states the password rules
that ar...
6/30/2013 1212
Managing Passwords ( Complexity)
• Preferably the web application should have the functionality to
force th...
6/30/2013 1313
Storing Credentials
6/30/2013 1414
Storing Credentials
• Credentials are essential to authenticating the users and
granting them access to the...
6/30/2013 1515
Storing Credentials
• Credentials should NOT be stored in the database in a clear text
form.
6/30/2013 1616
Storing Credentials
• Passwords should be hashed rather than encrypted.
• Hashing is a one way function, wh...
6/30/2013 1717
Storing Credentials (Salting)
• Salts are stored in plain text in the database along with the
Username and ...
6/30/2013 1818
Storing Credentials (Salting)
• Make sure that the passwords are salted before being hashed
and then stored...
6/30/2013 1919
Storing Credentials (Salting)
• Rainbow tables are precalculated databases of all possible hash
values.
Pas...
6/30/2013 2020
Storing Credentials (Salting)
• Attackers use them to find the passwords by comparing the
hashes of pre-cal...
6/30/2013 2121
Storing Credentials (Salting)
• Salting makes it hard for the attacker to mass “de-hash” the
leaked passwor...
6/30/2013 2222
Storing Credentials (Salting)
Leaked Salted Database RainBow Table (Precalculated Hashes) + Salt = abde312
...
6/30/2013 2323
Storing Credentials (Salting)
• How to validate the credentials with the stored salted hash?
6/30/2013 2424
Secure and Un-Secure Practices
6/30/2013 2525
Secure & UnSecure Practices
• Never send the user his/her password, neither via email nor via
any other for...
6/30/2013 2626
Secure & UnSecure Practices
• Never send the user his/her password, neither via email nor via
any other for...
6/30/2013 2727
Secure & UnSecure Practices
• In case the user has forgotten his password and clicked on the “I
forgot my p...
6/30/2013 2828
2-Factor Authentication
6/30/2013 2929
2-Factor Authentication
• 2-Factor Authentication requires an additional input to the
traditional username ...
6/30/2013 3030
2-Factor Authentication
• 2-FA OTP via Mobile Phone
6/30/2013 3131
2-Factor Authentication
• 2-FA OTP via Security Token
6/30/2013 3232
2-Factor Authentication
• 2-FA via Digital Certificate
6/30/2013 3333
2-Factor Authentication
Case Study - Dropbox
6/30/2013 3434
Case Study -
• Case Study of Dropbox’s flawed implementation of 2-FA.
• Discovered and reported by Zouheir ...
6/30/2013 3535
Case Study -
• Vulnerability
2-FA could be disabled for any person given that the
attacker knows the userna...
6/30/2013 3636
Case Study -
• Vulnerability
As mentioned earlier, the emergency backup code is
flawed. The code of one acc...
6/30/2013 3737
Case Study -
• Vulnerability
Dropbox didn’t disclose what the vulnerability was, but
according to QCERT’s a...
6/30/2013 3838
Case Study -
• Vulnerability
6/30/2013 396/30/2013 39
Questions?
Visit us on www.QCERT.org
Upcoming SlideShare
Loading in …5
×

Secure management of credentials - Zouheir Abdulla

609 views
549 views

Published on

Presented in OWASP Qatar Chapter Meeting - June 2013

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
609
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Secure management of credentials - Zouheir Abdulla

  1. 1. Secure Management of Credentials Zouheir Abdallah, CISA Senior Risk Specialist – CS/QCERT
  2. 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. 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. 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. 5. 6/30/2013 44 Managing User IDs
  6. 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. 7. 6/30/2013 66 Managing User IDs
  8. 8. 6/30/2013 77 Managing Passwords
  9. 9. 6/30/2013 88 Managing Passwords • In traditional authentication methods, the password and the User ID provide basic authentication.
  10. 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. 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. 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. 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. 14. 6/30/2013 1313 Storing Credentials
  15. 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. 16. 6/30/2013 1515 Storing Credentials • Credentials should NOT be stored in the database in a clear text form.
  17. 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. 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. 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. 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. 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. 22. 6/30/2013 2121 Storing Credentials (Salting) • Salting makes it hard for the attacker to mass “de-hash” the leaked passwords.
  23. 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. 24. 6/30/2013 2323 Storing Credentials (Salting) • How to validate the credentials with the stored salted hash?
  25. 25. 6/30/2013 2424 Secure and Un-Secure Practices
  26. 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. 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. 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. 29. 6/30/2013 2828 2-Factor Authentication
  30. 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. 31. 6/30/2013 3030 2-Factor Authentication • 2-FA OTP via Mobile Phone
  32. 32. 6/30/2013 3131 2-Factor Authentication • 2-FA OTP via Security Token
  33. 33. 6/30/2013 3232 2-Factor Authentication • 2-FA via Digital Certificate
  34. 34. 6/30/2013 3333 2-Factor Authentication Case Study - Dropbox
  35. 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. 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. 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. 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. 39. 6/30/2013 3838 Case Study - • Vulnerability
  40. 40. 6/30/2013 396/30/2013 39 Questions? Visit us on www.QCERT.org

×