SlideShare a Scribd company logo

Getting authentication right

•
•
A
Andre N. Klingsheim

The document discusses authentication and identity. It covers common authentication factors like passwords, two-factor authentication using a mobile phone, and biometrics. It provides details on securely storing passwords using techniques like salts and hash functions to prevent cracking. It also discusses risks of password reuse across sites and how two-factor authentication helps address this. The document emphasizes the importance of secure authentication and not allowing the security level to be degraded without re-authentication.

Related slideshows

Brute force attack
Brute force attackBrute force attack
Brute force attack
 
Password Attack
Password AttackPassword Attack
Password Attack
 
Securing Database Passwords Using a Combination of hashing and Salting Techni...
Securing Database Passwords Using a Combination of hashing and Salting Techni...Securing Database Passwords Using a Combination of hashing and Salting Techni...
Securing Database Passwords Using a Combination of hashing and Salting Techni...
 
1 of 39
Download to read offline
ROOTS, 27. April 2012 André N. Klingsheim @klingsen
 Some motivation  Authentication/identities defined  Where authentication fits in  Authentication factors  Passwords  Two-factor authentication  Keeping your shields up  Fun and demos
 Verizon Data Breach Investigations Report*  Based on 855 incidents (that resulted in)  174 million compromized records  Leads to some interesting statistics ▪ Curiosity: One organized criminal group in Eastern Europe worked on average three days per week  Go read it when you get home! * http://www.verizonbusiness.com/dbir/
Source: Verizon Data Breach Investigations Report, p. 26
Source: Verizon Data Breach Investigations Report, p. 32
 TL;DR: How sure are you that it’s the correct user who’s logging in?  You’re never 100% sure!  Authentication is the process of establishing an understood level of trust in whether the user is who she claims to be
 An identifier such as a name, national identity number, or a customer number, points to an identity  The identity of an individual is the set of information associated with that individual in a particular computer system
Someone claims to be «klings»! Authentication tries to establish whether that someone is this guy! 
1. You don’t know who the user is 2. The user authenticates (now you’re pretty sure who the user is) 3. The user gets a security token in return  You associate the user’s identity with this token  Think session cookies (and username written to session) 4. Now you «remember» the outcome of the authentication
 You’re done with authentication, and then have to rely on session security  So, authentication helps you figure out whether an unkown person/computer can safely be assosciated with a digital identity  Session security deals with remembering who the users is in a secure manner
Getting authentication right
 Your trust in that you’re talking to the right person is at its peak in the authentication instant  Session security takes over, remember this is «cached» trust  Re-authentication  Rebuilds your trust in that it’s still the correct person acting as the logged in user
Getting authentication right
 Something you know («Pa$$W0rd1»)  Something you have  Something you are * Fingerprint shared by Wilfredor under CC BY-SA 3.0 lisence
 In practice a static, shared secret  Password  Security questions ▪ Mother’s maiden name ▪ Where did you go to school ▪ And so on...  PINs (debit/credit cards)
 Code generators  Sequence based  Time-based  Your mobile phone  SMS  Google Authenticator  You’re debit/credit card (physical/VVC2)  Cards with printed PIN-codes
 Biometrics  Fingerprint  Retina scan  Etc..  Not widely deployed on the web...
 Something you know: a password or PIN  Why?  Very cheap (no devices) ▪ Do note that password resets can cost you…  In some cases available off-the-shelf (e.g. ASP.NET has the SqlMembershipProvider)  Scales well  Users are well accustomed to passwords/PINs!
 Som critical aspects of a password based authentication procedure  How passwords are stored  How users sign up  How passwords are validated  How passwords are reset  Application security  The security of all other password based IT- systems in the world
 The easiest way to store a password is, well, to store the password in a database in cleartext  DBA’s can easily steal the passwords.  A breach of the database will immediately reveal all passwords (think Sony)  So, encryption or hashing to the rescue!  PS! Forgot password -> mail with old password -> most likely cleartext passwords
 Encrypted passwords mean only one thing  They must be decrypted to be verified  Encryption key + database -> all passwords  There is most likely a sysadmin with access to both the key, and the db  Password encryption is not recommended!
 A hash function is a deterministic one way function with a fixed output length  Commonly used: MD5, Sha-1, Sha-256  MD5(‘Password’) => 3GR+tl5nEeFVN1IYISs5ZA==  Look it up on Google   It’s easy to compute the hash value of an input. It should be impossible to calculate the input based on a hash value (hence one way)
 Two users with the same password, will have the same hash values in the db  You can compute the hash value for common passwords, and store the values  If you get hold of password hashes – just look them up against known values!  The precomputation step is the essence of Rainbow tables  Let’s you crack common passwords in no time  We need salts!
 Salts add a bit of uniqueness to the input to the hash function  Salts can be stored besides the password hash in the db  Salt: 3GR+tl5nEeFVN1IYISs5ZA==  Hash = Sha-256(salt+password)  Hampers rainbow table attacks  Does not hamper dictionary attacks/brute force attacks
 If you get your hands on a list of salted password hashes you can  Run a dictionary attack (calculate password hashes for a wordlist, and compare the hashes)  Run a brute force attack (calculate hashes for all possible passwords aaaaaa, aaaaab, aaaaac so on)  If it’s not your list of password hashes, do consider the legal aspects
 Are very efficient against common hashes such as MD5/Sha-family  Millions of hashes checked per second (single cpu)  Due to the fact that hash functions were designed to be fast (not to store passwords)  We need to add a workload!
 PBKDF2  Password based key derivation function  Runs X iterations of an HMAC (based on SHA-1) to generate a key  Computational penalty for password crackers  Bcrypt  Also adds computational load => time penalty  Scrypt  Based on a memory trade-off, to hamper special purpose hardware w/limited memory
 You’ve stored your passwords securely  The password crackers now hate you  Then some other site gets hacked and all their passwords are leaked  Who cares, you’re secure right?  Your users used the same password on your site...
 Users tend to reuse their passwords across websites  Other sites get hacked for various reasons  Leads to the compromise of accounts on your site!  But that’s not fair!  No it isn’t. The world is not fair, in case you haven’t noticed.
 Something you have  Is NOT shared between sites  Solves the «other sites were hacked» problem
 Time-based  Code typically generated based on a secret key, and the current time  Requires reliable clocks on both server and the code generating device  Sequence based  Pseudo random number generator, seeded with a secret key  Code generator and server generate same sequence of codes
 Go with time-based if you can  Limited TTL for your codes  Limited number of valid codes at any given time  Sequence based generators  Let’s you compute many codes that will be valid until used  E.g. take someone’s token, generate 5 codes, they’ll be valid until the victim tries to use a code
 Very important that security cannot be degraded in your system  Fallback from two-factor to single factor authentication  Disabling of security mechanisms without requiring authentication  E.g. to change the password, you need to enter the correct current password
 More complicated for two-factor authentication  If you can reset one factor with the other, it’s not really two-factor  Forgot password -> set new password, confirm with one time code  Lost mobile phone -> log in with password to change mobile number for one time codes  Beware such dependencies in your system!
 “Forgotten password”  Secret questions (are not)  E-mail  Snail mail  SMS
 Require re-authentication for all critical updates  Such as change of  Password  Phone number  E-mail address  Disabling of security mechanisms  And not with just one factor!
 If you have an optional security mechanism (e.g. one time codes)  You must require the user to use the security mechanism in order to turn it off  Else it’s useless!  So changing the «security level» must be done according to the current level of security
 Tutorial/demo!   Scenario: Someone is logged in to their Google account  Two-factor authentication enabled  You have figured out their password but don’t have access to their OTPs  Can you find any way to gain access to their acount, without OTPs, from another computer?
 Thank you for listening!  Find me on the web:  www.dotnetnoob.com  @klingsen

More Related Content

Getting authentication right

  • 1. ROOTS, 27. April 2012 André N. Klingsheim @klingsen
  • 2. Some motivation  Authentication/identities defined  Where authentication fits in  Authentication factors  Passwords  Two-factor authentication  Keeping your shields up  Fun and demos
  • 3. Verizon Data Breach Investigations Report*  Based on 855 incidents (that resulted in)  174 million compromized records  Leads to some interesting statistics ▪ Curiosity: One organized criminal group in Eastern Europe worked on average three days per week  Go read it when you get home! * http://www.verizonbusiness.com/dbir/
  • 4. Source: Verizon Data Breach Investigations Report, p. 26
  • 5. Source: Verizon Data Breach Investigations Report, p. 32
  • 6. TL;DR: How sure are you that it’s the correct user who’s logging in?  You’re never 100% sure!  Authentication is the process of establishing an understood level of trust in whether the user is who she claims to be
  • 7. An identifier such as a name, national identity number, or a customer number, points to an identity  The identity of an individual is the set of information associated with that individual in a particular computer system
  • 8. Someone claims to be «klings»! Authentication tries to establish whether that someone is this guy! 
  • 9. 1. You don’t know who the user is 2. The user authenticates (now you’re pretty sure who the user is) 3. The user gets a security token in return  You associate the user’s identity with this token  Think session cookies (and username written to session) 4. Now you «remember» the outcome of the authentication
  • 10. You’re done with authentication, and then have to rely on session security  So, authentication helps you figure out whether an unkown person/computer can safely be assosciated with a digital identity  Session security deals with remembering who the users is in a secure manner
  • 12. Your trust in that you’re talking to the right person is at its peak in the authentication instant  Session security takes over, remember this is «cached» trust  Re-authentication  Rebuilds your trust in that it’s still the correct person acting as the logged in user
  • 14. Something you know («Pa$$W0rd1»)  Something you have  Something you are * Fingerprint shared by Wilfredor under CC BY-SA 3.0 lisence
  • 15. In practice a static, shared secret  Password  Security questions ▪ Mother’s maiden name ▪ Where did you go to school ▪ And so on...  PINs (debit/credit cards)
  • 16. Code generators  Sequence based  Time-based  Your mobile phone  SMS  Google Authenticator  You’re debit/credit card (physical/VVC2)  Cards with printed PIN-codes
  • 17. Biometrics  Fingerprint  Retina scan  Etc..  Not widely deployed on the web...
  • 18. Something you know: a password or PIN  Why?  Very cheap (no devices) ▪ Do note that password resets can cost you…  In some cases available off-the-shelf (e.g. ASP.NET has the SqlMembershipProvider)  Scales well  Users are well accustomed to passwords/PINs!
  • 19. Som critical aspects of a password based authentication procedure  How passwords are stored  How users sign up  How passwords are validated  How passwords are reset  Application security  The security of all other password based IT- systems in the world
  • 20. The easiest way to store a password is, well, to store the password in a database in cleartext  DBA’s can easily steal the passwords.  A breach of the database will immediately reveal all passwords (think Sony)  So, encryption or hashing to the rescue!  PS! Forgot password -> mail with old password -> most likely cleartext passwords
  • 21. Encrypted passwords mean only one thing  They must be decrypted to be verified  Encryption key + database -> all passwords  There is most likely a sysadmin with access to both the key, and the db  Password encryption is not recommended!
  • 22. A hash function is a deterministic one way function with a fixed output length  Commonly used: MD5, Sha-1, Sha-256  MD5(‘Password’) => 3GR+tl5nEeFVN1IYISs5ZA==  Look it up on Google   It’s easy to compute the hash value of an input. It should be impossible to calculate the input based on a hash value (hence one way)
  • 23. Two users with the same password, will have the same hash values in the db  You can compute the hash value for common passwords, and store the values  If you get hold of password hashes – just look them up against known values!  The precomputation step is the essence of Rainbow tables  Let’s you crack common passwords in no time  We need salts!
  • 24.  Salts add a bit of uniqueness to the input to the hash function  Salts can be stored besides the password hash in the db  Salt: 3GR+tl5nEeFVN1IYISs5ZA==  Hash = Sha-256(salt+password)  Hampers rainbow table attacks  Does not hamper dictionary attacks/brute force attacks
  • 25. If you get your hands on a list of salted password hashes you can  Run a dictionary attack (calculate password hashes for a wordlist, and compare the hashes)  Run a brute force attack (calculate hashes for all possible passwords aaaaaa, aaaaab, aaaaac so on)  If it’s not your list of password hashes, do consider the legal aspects
  • 26. Are very efficient against common hashes such as MD5/Sha-family  Millions of hashes checked per second (single cpu)  Due to the fact that hash functions were designed to be fast (not to store passwords)  We need to add a workload!
  • 27. PBKDF2  Password based key derivation function  Runs X iterations of an HMAC (based on SHA-1) to generate a key  Computational penalty for password crackers  Bcrypt  Also adds computational load => time penalty  Scrypt  Based on a memory trade-off, to hamper special purpose hardware w/limited memory
  • 28. You’ve stored your passwords securely  The password crackers now hate you  Then some other site gets hacked and all their passwords are leaked  Who cares, you’re secure right?  Your users used the same password on your site...
  • 29. Users tend to reuse their passwords across websites  Other sites get hacked for various reasons  Leads to the compromise of accounts on your site!  But that’s not fair!  No it isn’t. The world is not fair, in case you haven’t noticed.
  • 30.  Something you have  Is NOT shared between sites  Solves the «other sites were hacked» problem
  • 31. Time-based  Code typically generated based on a secret key, and the current time  Requires reliable clocks on both server and the code generating device  Sequence based  Pseudo random number generator, seeded with a secret key  Code generator and server generate same sequence of codes
  • 32. Go with time-based if you can  Limited TTL for your codes  Limited number of valid codes at any given time  Sequence based generators  Let’s you compute many codes that will be valid until used  E.g. take someone’s token, generate 5 codes, they’ll be valid until the victim tries to use a code
  • 33. Very important that security cannot be degraded in your system  Fallback from two-factor to single factor authentication  Disabling of security mechanisms without requiring authentication  E.g. to change the password, you need to enter the correct current password
  • 34. More complicated for two-factor authentication  If you can reset one factor with the other, it’s not really two-factor  Forgot password -> set new password, confirm with one time code  Lost mobile phone -> log in with password to change mobile number for one time codes  Beware such dependencies in your system!
  • 35. “Forgotten password”  Secret questions (are not)  E-mail  Snail mail  SMS
  • 36. Require re-authentication for all critical updates  Such as change of  Password  Phone number  E-mail address  Disabling of security mechanisms  And not with just one factor!
  • 37. If you have an optional security mechanism (e.g. one time codes)  You must require the user to use the security mechanism in order to turn it off  Else it’s useless!  So changing the «security level» must be done according to the current level of security
  • 38. Tutorial/demo!   Scenario: Someone is logged in to their Google account  Two-factor authentication enabled  You have figured out their password but don’t have access to their OTPs  Can you find any way to gain access to their acount, without OTPs, from another computer?
  • 39. Thank you for listening!  Find me on the web:  www.dotnetnoob.com  @klingsen