Getting authentication right

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 identiﬁer 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

 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

 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

Getting authentication right

More Related Content

What's hot (20)

Similar to Getting authentication right (20)

Recently uploaded (20)

Getting authentication right