Successfully reported this slideshow.

Getting authentication right

1

Share

Loading in …3
×
1 of 39
1 of 39

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Getting authentication right

  1. 1. ROOTS, 27. April 2012 André N. Klingsheim @klingsen
  2. 2.  Some motivation  Authentication/identities defined  Where authentication fits in  Authentication factors  Passwords  Two-factor authentication  Keeping your shields up  Fun and demos
  3. 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. 4. Source: Verizon Data Breach Investigations Report, p. 26
  5. 5. Source: Verizon Data Breach Investigations Report, p. 32
  6. 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. 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. 8. Someone claims to be «klings»! Authentication tries to establish whether that someone is this guy! 
  9. 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. 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
  11. 11.  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
  12. 12.  Something you know («Pa$$W0rd1»)  Something you have  Something you are * Fingerprint shared by Wilfredor under CC BY-SA 3.0 lisence
  13. 13.  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)
  14. 14.  Code generators  Sequence based  Time-based  Your mobile phone  SMS  Google Authenticator  You’re debit/credit card (physical/VVC2)  Cards with printed PIN-codes
  15. 15.  Biometrics  Fingerprint  Retina scan  Etc..  Not widely deployed on the web...
  16. 16.  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!
  17. 17.  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
  18. 18.  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
  19. 19.  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!
  20. 20.  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)
  21. 21.  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!
  22. 22.  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
  23. 23.  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
  24. 24.  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!
  25. 25.  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
  26. 26.  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...
  27. 27.  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.
  28. 28.  Something you have  Is NOT shared between sites  Solves the «other sites were hacked» problem
  29. 29.  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
  30. 30.  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
  31. 31.  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
  32. 32.  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!
  33. 33.  “Forgotten password”  Secret questions (are not)  E-mail  Snail mail  SMS
  34. 34.  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!
  35. 35.  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
  36. 36.  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?
  37. 37.  Thank you for listening!  Find me on the web:  www.dotnetnoob.com  @klingsen

×