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/
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
11.
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
13.
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!
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