CS 2550 Foundations of

Cybersecurity
Passwords and Authentication
Authentication
• Authentication is the process of verifying an actor’s identity
• Critical for security of systems
• Permissions, capabilities, and access control are all contingent upon
knowing the identity of the actor
• Typically parameterized as a username and a secret
• The secret attempts to limit unauthorized access
• Desirable properties of secrets include being unforgeable,
unguessable, and revocable
Types of Secrets
• Actors provide their secret to log-in to a system
• Three classes of secrets:
1. Something you know
• Example: a password
2. Something you have
• Examples: a smart card or smart phone
3. Something you are
• Examples: fingerprint, voice scan, iris scan

4
Password Storage
Hashing and Salting
Key Stretching and Work Factor
Honeywords
 Attacker Goals and Threat Model
• Assume we have a system storing usernames and passwords
• The attacker has access to the password database/file

I wanna login to
those user accounts!
Database

Cracked Passwords
User Password User Password
cbw p4ssW0rd cbw p4ssW0rd
sandi puppies sandi puppies
amislove 3spr3ss0 amislove 3spr3ss0
Checking Passwords
• System must validate passwords provided by users
• Thus, passwords must be stored somewhere
• Basic storage: plain text

password.txt

cbw p4ssw0rd
sandi i heart doggies
amislove 93Gd9#jv*0x3N
bob security
Problem: Password File Theft
• Attackers often compromise systems
• They may be able to steal the password file
• Linux: /etc/shadow
• Windows: c:\windows\system32\config\sam
• If the passwords are plain text, what happens?
• The attacker can now log-in as any user, including root/administrator
• Passwords should never be stored in plain text
Hashed Passwords
• Key idea: store hashed versions of passwords
• Use one-way cryptographic hash functions
• Examples: MD5, SHA1, SHA256, SHA512, bcrypt, PBKDF2, scrypt
• Cryptographic hash function transform input data into
scrambled output data
• Deterministic: hash(A) = hash(A)
• High entropy:
• MD5(‘security’) = e91e6348157868de9dd8b25c81aebfb9
• MD5(‘security1’) = 8632c375e9eba096df51844a5a43ae93
• MD5(‘Security’) = 2fae32629d4ef4fc6341f1751b405e45
• Collision resistant
• Locating A’ such that hash(A) = hash(A’) takes a long time (hopefully)
• Example: 221 tries for md5
Hashed Password Example
MD5(‘p4ssw0rd’) =
2a9d119df47ff993b662a8ef36f9ea20
User: cbw

MD5(‘2a9d119df47ff993b662a8ef36f9ea20’)
= b35596ed3f0d5134739292faa04f7ca3

hashed_password.txt

cbw 2a9d119df47ff993b662a8ef36f9ea20
sandi 23eb06699da16a3ee5003e5f4636e79f
amislove 98bd0ebb3c3ec3fbe21269a8d840127c
bob e91e6348157868de9dd8b25c81aebfb9
Attacking Password Hashes
• Recall: cryptographic hashes are collision resistant
• Locating A’ such that hash(A) = hash(A’) takes a long time (hopefully)
• Are hashed password secure from cracking?
• No!
• Problem: users choose poor passwords
• Most common passwords: 123456, password
• Username: cbw, Password: cbw
• Weak passwords enable dictionary attacks
Most Common Passwords
Rank 2013 2014 2020
1 123456 123456 123456
2 password password 123456789
3 12345678 12345 picture1
4 qwerty 12345678 password
5 abc123 qwerty 12345678
6 123456789 123456789 111111
7 111111 1234 123123
8 1234567 baseball 12345
9 iloveyou dragon 1234567890
10 adobe123 football senha
Dictionary Attacks
hash(
)
English List of hashed_
Dictionary possible password.txt
password
hashes
hash()

Common
Passwords

• Common for 60-70% of hashed passwords to be cracked in <24 hours

Hardening Password Hashes
• Key problem: cryptographic hashes are deterministic
• hash(‘p4ssw0rd’) = hash(‘p4ssw0rd’)
• This enables attackers to build lists of hashes
• Solution: make each password hash unique
• Add a random salt to each password before hashing
• hash(salt + password) = password hash
• Each user has a unique, random salt
• Salts can be stores in plain text
 Example Salted Hashes
hashed_password.txt

cbw 2a9d119df47ff993b662a8ef36f9ea20
sakib 23eb06699da16a3ee5003e5f4636e79f
amislove 98bd0ebb3c3ec3fbe21269a8d840127c User: cbw
bob e91e6348157868de9dd8b25c81aebfb9

hashed_and_salted_password.txt
MD5(‘a8’ + ‘p4ssw0rd’) =
cbw a8 af19c842f0c781ad726de7aba439b033 af19c842f0c781ad726de7aba439b033
sakib 0X 67710c2c2797441efb8501f063d42fb6
amislove hz 9d03e1f28d39ab373c59c7bb338d0095
bob K@ 479a6d9e59707af4bb2c618fed89c245
Attacking Salted Passwords
No matches

List of hashed_
hash() possible and_salted_
password password.txt
hashes

cbw a8
List of
sakib 0X List of
possible
hash(‘a8’ + word) possible
password cbw XXXX
hash(‘0X’ + word) sakib YYYY
password
hashes w/
hashes
salt a8 w/
salt 0X
Breaking Hashed Passwords
• Stored passwords should always be salted
• Forces the attacker to brute-force each password individually
• Problem: it is now possible to compute hashes very quickly
• GPU computing: hundreds of small CPU cores
• nVidia GeForce GTX Titan Z: 5,760 cores
• GPUs can be rented from the cloud very cheaply
• $0.9 per hour (2018 prices)
Examples of Hashing Speed
• A modern x86 server can hash all possible 6 character long
passwords in 3.5 hours
• Upper and lowercase letters, numbers, symbols
• (26+26+10+32)6 = 690 billion combinations
• A modern GPU can do the same thing in 16 minutes
• Most users use (slightly permuted) dictionary words, no symbols
• Predictability makes cracking much faster
• Lowercase + numbers  (26+10)6 = 2B combinations
Hardening Salted Passwords
• Problem: typical hashing algorithms are too fast
• Enables GPUs to brute-force passwords
• Old solution: hash the password multiple times
• Known as key stretching
• Example: crypt used 25 rounds of DES
• New solution: use hash functions that are designed to be slow
• Examples: bcrypt, PBKDF2, scrypt
• These algorithms include a work factor that increases the time
complexity of the calculation
• scrypt also requires a large amount of memory to compute, further
complicating brute-force attacks
bcrypt Example
• Python example; install the bcrypt package

[cbw@localhost ~] python Work factor

>>> import bcrypt
>>> password = “my super secret password”
>>> fast_hashed = bcrypt.hashpw(password, bcrypt.gensalt(0))
>>> slow_hashed = bcrypt.hashpw(password, bcrypt.gensalt(12))
>>> pw_from_user = raw_input(“Enter your password:”)
>>> if bcrypt.hashpw(pw_from_user, slow_hashed) == slow_hashed:
… print “It matches! You may enter the system”
… else:
… print “No match. You may not proceed”

20
Password Storage Summary
1. Never store passwords in plain text
2. Always salt and hash passwords before storing them
3. Use hash functions with a high work factor

• These rules apply to any system that needs to authenticate users

• Operating systems, websites, etc.
Password Recovery and
Reset
Password Recovery/Reset
• Problem: hashed passwords cannot be recovered (hopefully)

“Hi… I forgot my password. Can

you email me a copy? Kthxbye”

• This is why systems typically implement password reset

– Use out-of-band info to authenticate the user
– Overwrite hash(old_pw) with hash(new_pw)
• Be careful: its possible to crack password reset
Knowledge-based Reset
• Typical implementations use Knowledge Based Authentication (KBA)
• What was your mother’s maiden name?
• What was your prior street address?
• Where did you go to elementary school
• Problems?
• This information is widely available to anyone
• Publicly accessible social network profiles
• Background-check services like Spokeo
• Experts recommend that services not use KBA
• When asked, users should generate random answers to these questions
Account-based Reset
• Idea: authenticate a user by sending a code to their contact address
• Typically e-mail address or phone number
• Security rests on the assumption that the person’s contact address is
also secure
• E-mail account takeover
• SIM hijacking
Challenges of Password Reset
• Password reset mechanisms are often targeted and are quite
vulnerable
• Best practice: implement a layered mechanism
• Knowledge-based
• Secondary account
• Second factor authentication: biometric or tokens
• Warning: more secure = less usable
• Password loss is common, people will be frustrated by onerous reset
mechanisms
Password Cracking

Password Theory
Hash Chains
Rainbow Tables
 Attacker Goals and Threat Model
• Assume we have a system storing usernames and passwords
• The attacker has access to the password database/file

I wanna login to
those user accounts!
Database

Cracked Passwords
User H(PW) User Password
cbw iuafNas cbw p4ssW0rd
sandi 23asZR sandi puppies
amislove 9xgGw/ amislove 3spr3ss0
Basic Password Cracking
• Problem: humans are terrible at generating/remembering random
strings
• Passwords are often weak enough to be brute-forced
• Naïve way: systematically try all possible passwords
• Slightly smarter way: take into account non-uniform distribution of characters
• Dictionary attacks are also highly effective
• Select a baseline wordlist/dictionary full of likely passwords
• Today, the best wordlists come from lists of breached passwords
• Rule-guided word mangling to look for slight variations
• E.g. password  Password  p4ssword  passw0rd  p4ssw0rd  password1  etc.
• Many password cracking tools exist (e.g. John the Ripper, hashcat)
“Deep Crack”: The EFF DES Cracker
• DES uses a 56-bit key
• $250K in 1998, capable of brute-
forcing DES keys in 56 hours
• Uses 1856 custom ASIC chips
• Similar attacks have been
demonstrated against MD5, SHA1
• Modern equivalent?
• Bitcoin mining ASICs
Speeding Up Brute-Force Cracking
• Brute force attacks are slow because hashing is CPU intensive
• Especially if a strong function (SHA512, bcrypt) is used
• Idea: why not pre-compute and store all hashes?
• You would only need to pay the CPU cost once…
• … for a given salt
• Given a hash function H, a target hash h, and password space P, goal
is to recover such that
• Problem: naïve approach requires Θ(|P|n) bits, where n is the space
of the output of H
Hash Chains
• Hash chains enable time-space efficient reversal of hash functions
• Key idea: pre-compute chains of passwords of length k…
• … but only store the start and end of each chain
• Larger k  fewer chains to store, more CPU cost to rebuild chains
• Small k  more chains to store, less CPU cost to rebuild chains
• Building chains require H, as well as a reduction R : H ↦ P
• Begin by selecting some initial set of password
• For each ’, apply for k iterations
• Only store and
• To recover hash h, apply R and H until the end of a chain is found
• Rebuild the chain using and
• H(p) = h may be within the chain
Uncompressed Hash Chain Example
Only these two columns
get stored on disk

p' H(p’) = h’ R(h’) = p” H(p”) = h” R(h”) = p’’’ H(p’’’) = h’’’ R(h’’’) = p*

abcde \\WPNP_ vlsfqp _QOZLR eusrqv CMRQ5X cjldar
passw VZDGEF gfnxsk ZLGEKV yookol EBOTHT zvxscs
K=3
12345 SM-QK\9 sawtzg RHKP_D gvmdwm BYE4LB wjizbn
secrt OKFTaY btweoz WA15HK ttgovl Q_4\6ZB eivlqc
 Hash Chain Example
p' p* • Size of the table is dramatically
abcde cjldar reduced…
passw zvxscs
K=3 • … but some computation is necessary
12345 wjizbn
secrt eivlqc once a match is found

p' H(p’) = h’ R(h’) = p” H(p”) = h” R(h”) = p’’’ H(p’’’) = h’’’ R(h’’’) = p*

12345 SM-QK\9 sawtzg RHKP_D wjizbn

p H(p) = h R(h) = p’ H(p’) = h’ R(h’) = p” H(p”) = h” R(h”) = p’’’ H(p’’’) = h’’’

sawtzg RHKP_D gvmdwm BYE4LB wjizbn

Desired password Hash to recover

Problems with Hash Chains
• Hash chains are prone to collisions
• Collisions occur when H(p’) = H(p”) or R(h’) = R(h”) (the latter is more likely)
• Causes the chains to merge or overlap
• Problems caused by collisions
• Wasted space in the file, since the chains cover the same password space
• False positives: a chain may not include the password even if the end matches
• Proper choice of R() is critical
• Goal is to cover likely password space, not entire password space
• R cannot be collision resistant (like H) since it has to map into likely plaintexts
• Difficult to select R under this criterion
Rainbow Tables
• Rainbow tables improve on hash chains by reducing the likelihood of
collisions
• Key idea: instead of using a single reduction R, use a family of
reductions {R1, R2, … , Rk}
• Usage of H is the same as for hash chains
• A collisions can only occur between two chains if it happens at the same
position (e.g. Ri in both chains)
Final Thoughts on Rainbow Tables
• Caveats
• Tables must be built for each hash function and character set
• Salting and key stretching defeat rainbow tables
• Rainbow tables are effective in some cases, e.g. MD5 and NTLM
• Precomputed tables can be bought or downloaded for free
Measuring Password
Strength
Password Quality

• How do we measure password quality? Entropy

• N – the number of possible symbols (e.g. lowercase, uppercase, numbers, etc.)
• L – the length of the password
• S – the strength of the password, in bits
• Formula tells you length L needed to achieve a desired strength S…
• … for randomly generated passwords
• Is this a realistic measure in practice?
 The Strength of Random Passwords
𝑆=𝐿 ∗𝑙𝑜𝑔2 𝑁
200
175 26+26+10 Characters Very
150 26+26 Characters Strong
Strength (Bits)

125 26 Characters
100
75
50
Very
25 Weak
0
0 5 10 15 20 25 30 35

Password Length (Characters)

Choosing Passwords
Bad Algorithms
Better Heuristics
Password Reuse
Mental Algorithms
• Years of security advice have trained people to generate “secure”
passwords

1. Pick a word
2. Capitalize the first or last letter
3. Add a number (and maybe a symbol) to the beginning or end

4. Pick a word
5. Replace some of the letters with symbols (a  @, s  $, etc.)
6. Maybe capitalize the first or last letter
 Human Generated Passwords
Password Entropy (bits) Strength Crackability Problem
Computer3@ 60 Weak Easy Dictionary word, obvious transformations
cl4ssr00m 47 Weak Easy Dictionary word, obvious transformations
7Dogsled* 54 Weak Easy Dictionary word, obvious transformations
Tjw1989&6 54 Weak Easy Users initials and birth year, obvious transformations
B4nk0f4m3r1c4! 83 Medium Easy Includes service name, obvious transformations

• Modern attackers are sophisticated

• No need for brute force cracking!
• Use dictionaries containing common words and passwords from prior leaks
• Apply common “mental” permutations
 Password Requirements
• comp n and basic n: use at least n
characters

• k word n: combine at least k words

using at least n characters

• d class n: use at least d character

types (upper, lower, digit, symbol)
with at least n characters

Plot from Shay et al.

https://www.blaseur.com/papers/tissec_1026.pdf
Better Heuristics
• Notice that in , length matters more than symbol
types
• Choose longer passwords (16+ characters)
• Don’t worry about uppercase, digits, or symbols

• Use mnemonics
• Choose a sentence or phrase
• Reduce it to the first letter of each word
• Insert random uppercase, digits, and symbols

I double dare you, say “what” one more time

i2Dy,s”w”omt
Password Management
Password Reuse
• People have difficulty remembering >4 passwords
• Thus, people tend to reuse passwords across services
• What happens if any one of these services is compromised?
• Service-specific passwords are a beneficial form of
compartmentalization
• Limits the damage when one service is inevitably breaches
• Use a password manager
• Some service providers now check for password reuse
• Forbid users from selecting passwords that have appeared in leaks
Biometric Two Factor
Authentication
Biometrics

SMS

Authentication Codes

Smartcards & Hardware Tokens

Types of Secrets
• Actors provide their secret to log-in to a system
• Three classes of secrets:
1. Something you know
• Example: a password
2. Something you have
• Examples: a smart card or smart phone
3. Something you are
• Examples: fingerprint, voice scan, iris scan

55
Biometrics
• ancient Greek: bios ="life", metron ="measure“
• Physical features
• Fingerprints
• Face recognition
• Retinal and iris scans
• Hand geometry
• Behavioral characteristics
• Handwriting recognition
• Voice recognition
• Typing cadence
• Gait
Fingerprints
• Ubiquitous on modern smartphones, some laptops
• Secure?
• May be subpoenaed by law enforcement
• Relatively easy to compromise
1. Pick up a latent fingerprint (e.g. off a glass) using tape or
glue
2. Photograph and enhance the fingerprint
3. Etch the print into gelatin backed by a conductor
4. Profit ;)

https://www.theregister.co.uk/2002/05/16/gummi_bears_defeat_fingerprint_sensors/
Facial Recognition
• Popularized by FaceID on the iPhone X
• Secure?
• It depends
• Vulnerable to law enforcement requests
• Using 2D images?
• Not secure
• Trivial to break with a photo of the target’s face
• Using 2D images + 3D depth maps?
• More secure, but not perfect
• Can be broken by crafting a lifelike mask of the target
Voice Recognition
• Secure?
• Very much depends on the implementation
• Some systems ask you to record a static phrase
• E.g. say “unlock” to unlock
• This is wildly insecure
• Attacker can record and replay your voice
• Others ask you to train a model of your voice
• Train the system by speaking several sentences
• To authenticate, speak several randomly chosen words
• Not vulnerable to trivial replay attacks, but still vulnerable
• Given enough samples of your voice, an attacker can train a synthetic voice AI that
sounds just like you
Fundamental Issue With Biometrics
• Biometrics are immutable
• You are the password, and you can’t change
• Unless you plan on undergoing plastic surgery?
• Once compromised, there is no reset
• Passwords and tokens can be changed
• Example: the Office of Personnel Management (OPM) breach
• US gov agency responsible for background checks
• Had fingerprint records of all people with security clearance
• Breached by China in 2015, all records stolen :(
Token-based Two Factor
Authentication
Types of Secrets
• Actors provide their secret to log-in to a system
• Three classes of secrets:
1. Something you know
• Example: a password
2. Something you have
• Examples: a smart card or smart phone
3. Something you are
• Examples: fingerprint, voice scan, iris scan

63
Something You Have
• Two-factor authentication has become more commonplace
• Possible second factors:
• SMS passcodes
• Time-based one time passwords
• Hardware tokens
SMS Two Factor
• Relies on your phone number as the second factor
• Key assumption: only your phone should receive SMS
sent to your number
• SMS two factor is deprecated. Why?
• Social engineering the phone company
1. Call and pretend to be the victim
2. Say “I got a new SIM, please activate it”
3. If successful, phone calls and SMS are now sent to your
SIM in your phone, instead of the victim
• Not hypothetical: successfully used against many
victims
One Time Passwords
Changes
• Generate ephemeral passcodes that every few
change over time minutes
• To login, supply normal password and
the current one time password
• Relies on a shared secret between
your mobile device and the service
provider Duo Mobile
• Shared secret allows both parties to
know the current one time password Lastpass Authenticator

Google Authenticator
Time-based One-time Password Algorithm
T0 = <the beginning of time, typically Thursday, 1 January 1970 UTC>
TI = <length of time the password should be valid>
K = <shared secret key>
d = <the desired number of digits in the password>
TC = floor((unixtime(now) − unixtime(T0)) / TI),
TOTP = HMAC(K, TC) % 10d

Given K, this algorithm can

Specially formatted be run on your phone and by
SHA1-based signature the service provider
Secret Sharing for TOTP
Hardware Two Factor
• Special hardware designed to hold
cryptographic keys
• Physically resistant to key extraction
attacks
• E.g. scanning tunneling electron
microscopes
• Uses:
• 2nd factor for OS log-on
• 2nd factor for some online services
• 2nd factor for password manager
• Storage of PGP and SSH keys
Universal 2nd Factor (U2F)
• Supported by Chrome, Opera, and Firefox

• Works with Google, Dropbox, Facebook,

Github, Gitlab, etc.

• Pro tip: always buy 2 security keys

• Associate both with your accounts
• Keep one locked in a safe, in case you lose your
primary key ;)
Authentication in Linux
Unix, PAM, and crypt
Network Information Service (NIS, aka Yellow Pages)
Needham-Schroeder and Kerberos
Status Check
• At this point, we have discussed:
• How to securely store passwords
• Techniques used by attackers to crack passwords
• Biometrics and 2nd factors
• Next topic: building authentication systems
• Given a user and password, how does the system authenticate the user?
• How can we perform efficient, secure authentication in a distributed system?
Authentication in Unix/Linux
• Users authenticate with the system by interacting with login
• Prompts for username and password
• Credentials checked against locally stored credentials
• By default, password policies specified in a centralized, modular way
• On Linux, using Pluggable Authentication Modules (PAM)
• Authorizes users, as well as environment, shell, prints MOTD, etc.
Example PAM Configuration
# cat /etc/pam.d/system-auth
#%PAM-1.0

auth required pam_unix.so try_first_pass nullok

auth optional pam_permit.so • Use SHA512 as the hash function
auth required pam_env.so • Use /etc/shadow for storage
account required pam_unix.so
account optional pam_permit.so
account required pam_time.so

password required pam_unix.so try_first_pass nullok sha512 shadow

password optional pam_permit.so

session required pam_limits.so

session required pam_unix.so
session optional pam_permit.so
Unix Passwords
• Traditional method: crypt
• First eight bytes of password used as key (additional bytes are ignored)
• 12-bit salt
• 25 iterations of DES on a zeroed vector
• Modern version of crypt are more extensible
• Full password used
• Up to 16 bytes of salt
• Support for additional hash functions like MD5, SHA256, and SHA512
• Key lengthening: defaults to 5000 iterations, up to 108 – 1
Password Files
• Password hashes used to be in /etc/passwd
• World readable, contained usernames, password hashes, config information
• Many programs read config info from the file…
• But very few (only one?) need the password hashes
• Turns out, world-readable hashes are Bad Idea
• Hashes now located in /etc/shadow
• Also includes account metadata like expiration
• Only visible to root
 Password Storage on Linux
/etc/passwd

username:x:UID:GID:full_name:home_directory:shell

cbw:x:1001:1000:Christo Wilson:/home/cbw/:/bin/bash
amislove:1002:2000:Alan Mislove:/home/amislove/:/bin/sh
$<algo>$<salt>$<hash>
Algo: 1 = MD5, 5 = SHA256, 6 = SHA512
/etc/shadow

username:password:last:may:must:warn:expire:disable:reserved

cbw:$1$0nSd5ewF$0df/3G7iSV49nsbAa/5gSg:9479:0:10000::::
amislove:$1$l3RxU5F1$:8172:0:10000::::
77
Distributed Authentication
Distributed Authentication
• Early on, people recognized the need for authentication in distributed
environments
• Example: university lab with many workstations
• Example: file server that accepts remote connections
• Synchronizing and managing password files on each machine is not
scalable
• Ideally, you want a centralized repository that stores policy and credentials
The Yellow Pages
• Network Information Service (NIS), a.k.a. the Yellow Pages
• Developed by Sun to distribute network configurations
• Central directory for users, hostnames, email aliases, etc.
• Exposed through yp* family of command line tools
• For instance, depending on /etc/nsswitch.conf, hostname lookups can
be resolved by using
• /etc/hosts
• DNS
• NIS
• Superseded by NIS+, LDAP
 • Crypt based password hashes
NIS Password Hashes • Can easily be cracked
• Many networks still rely on insecure NIS

[cbw@workstation ~] ypcat passwd

afbjune:qSAH.evuYFHaM:14532:65104::/home/afbjune:/bin/bash
philowe:T.yUMej3XSNAM:13503:65104::/home/philowe:/bin/bash
bratus:2omkwsYXWiLDo:6312:65117::/home/bratus:/bin/tcsh
adkap:ZfHdSwSz9WhKU:9034:65118::/home/adkap:/bin/zsh
amitpoon:i3LjTqgU9gYSc:8198:65117::/home/amitpoon:/bin/tcsh
kcole:sgYtUsOtyk38k:14192:65104::/home/kcole:/bin/bash
david87:vA06wxjJEUgBE:13055:65101::/home/david87:/bin/bash
loch:6HgIQrVkcBeiw:13729:65104::/home/loch:/bin/bash
ppkk315:s6CTSAkqqr/nU:14061:65101::/home/ppkk315:/bin/bash
haynesma:JYWaQUARSqDQE:14287:65105::/home/haynesma:/bin/bash
ckubicek:jYpwYhqqvr3tA:10937:65117::/home/ckubicek:/bin/tcsh
mwalz:wPIa5Bv/tFVb2:9103:65118::/home/mwalz:/bin/tcsh
sushma:G6XNe18GpeQj.:13682:65104::/home/sushma:/bin/bash
guerin1:n0Da2TmO9MDBI:14512:65105::/home/guerin1:/bin/bash
 Distributed Authentication Revisited
Auth Server
• Goal: a user would like to use
some resource on the network
• File server, printer, database, cbw
mail server, etc.
• Problem: access to resources Database
requires authentication
• Auth Server contains all
credential information
• You do not want to replicate the
credentials on all services
 Attacker Goals and Threat Model
Auth Server
• Goal: steal credentials and gain
access to protected resources
• Local attacker – may spy on cbw
traffic
• Active attacker – may send Database

messages
• In some cases, may be able to
steal information from users

I wanna access the

Database too ;)
(Bad) Distributed Auth Example Looks good!

Auth Server
• Idea: client forwards
user/password to service,
service queries Auth Server cbw
• Problems:
• Passwords being sent in the clear Database
• Attacker can observe them!
• Clearly we need encryption
cbw:p4ssw0rd
• Database learns about passwords
• Additional point of compromise
• Ideally, only the user and the Auth Please verify
Server should know their password cbw:p4ssw0rd cbw:p4ssw0rd
Needham-Schroeder Protocol
• Let Alice A and Bob B be two parties that trust server S
• KAS and KBS are shared secrets between [A, S] and [B, S]
• KAB is a negotiated session key between [A, B]
• Ni and Nj are random nonces generated by A and B
KAS is not sent in the clear, authenticates S and A

KBS is not sent in the clear, authenticates B

Challenge nonce forces A to acknowledge they have KAB

Needham-Schroeder Example
{, Kcbw-db, db, {Kcbw-db, cbw}Kdb}Kcbw

Auth Server
cbw

db
cbw

cbw
Database
cbw-db
db
{}K, db,
cbw,
{Kcbw-db cbw}K
cbw-db
db cbw-db

{}K
cbw-db
 Attacking Needham-Schroeder
{, Kcbw-db, db, {Kcbw-db, cbw}Kdb}Kcbw
• Spoof the client request
• Fail! Client key is needed to decrypt
cbw Auth Server
• Spoof the Auth Server response
• Fail! Need to know the client key cbw cbw

• Spoof the client-server interaction db

• Fail! Need to know the database key
• Replay the client-server interaction cbw, db, Database
• Fail! Need to know the session key db

evil cbw-db

{, Kevil, db, {Kevil, cbw}

{K{Kcbw-db
cbw,
evil
K
, },cbw}
cbw}
db,K K
db Kcbw dbdb
{}K
cbw-db
 Replay Attack
Typical, Benign Protocol Replay Attack

• Attacker must hack A to steal KAB

• So the attacker can also steal KAS
• However, what happens after A changes KAS
• Attacker can still conduct the replay attack! Only is KAB necessary!
Fixed Needham-Schroeder Protocol
• Let Alice A and Bob B be two parties that trust server S
• KAS and KBS are shared secrets between [A, S] and [B, S]
• KAB is a negotiated session key between [A, B]
• Ni and Nj are random nonces generated by A and B
• T is a timestamp chosen by S

B only accepts requests

with fresh timestamps
Kerberos
• Created as part of MIT Project Athena
• Based on Needham-Schroeder
• Provides mutual authentication over untrusted networks
• Tickets as assertions of authenticity, authorization
• Forms basis of Active Directory authentication
• Principals
• Client
• Server
• Key distribution center (KDC)
• Authentication server (AS)
• Ticket granting server (TGS)
 {, Kcbw-tgs}Kcbw , TGT
Kerberos Example
Auth Server
cbw

tgt

{Kcbw-db}Kcbw-tgs , {Kcbw-db}Kdb
Ticket Granting
Server
cbw
tgt
TGT
cbw
db
cbw-tgs

{TGT, db,
cbw }K {cbw,
, {cbw,T}T}Kcbw-tgs
cbw-db Database
Kcbw-db Kcbw-db
db
db {T - 1}K
cbw-db

cbw-db
Attacking Kerberos
• Don’t put all your eggs in one basket
• The Kerberos Key Distribution Server (KDS) is a central point of failure
• DoS the KDS and the network ceases to function
• Compromise the KDS leads to network-wide compromise
• Time synchronization
• Inaccurate clocks lead to protocol failures (due to timestamps)
• Solution?
• Use NTP ;)
Sources
1. Many slides courtesy of Wil Robertson: https://wkr.io
2. Honeywords, Ari Juels and Ron Rivest: http://www.arijuels.com/wp-content/uploads/2013/09/JR13.pdf

• For more on generating secure passwords, and understanding people’s mental models of passwords, see the excellent
work of Blas Ur: http://www.blaseur.com/pubs.htm