Getting authentication right

39
ROOTS, 27. April 2012 André N. Klingsheim @klingsen

description

My talk at ROOTS 2012

Transcript of Getting authentication right

  • ROOTS, 27. April 2012Andr 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 its the correct user whos logging in? Youre 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 identier 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 dont know who the user is2. The user authenticates (now youre pretty sure who the user is)3. The user gets a security token in return You associate the users identity with this token Think session cookies (and username written to session)4. Now you remember the outcome of the authentication
  • Youre 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
  • Your trust in that youre 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 its still the correct person acting as the logged in user
  • 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 Mothers 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 Youre 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 DBAs 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 Its 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 Lets 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 its 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
  • Youve stored your passwords securely The password crackers now hate you Then some other site gets hacked and all their passwords are leaked Who cares, youre 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 thats not fair! No it isnt. The world is not fair, in case you havent 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 Lets you compute many codes that will be valid until used E.g. take someones token, generate 5 codes, theyll 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, its 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 its 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 dont 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