ADMINISTRATIVE
Project 2 has been released!
Network security is upcoming! To prepare, I have released a few
“Intro to Networking” videos, in case you haven’t taken a course on
networking before.
Final exam: Tue 12/13 08:00a - 10:00a RHPH 172
CURRENT EVENTS?
USER AUTHENTICATION
CS 526
Christina Garman
USER AUTHENTICATION
BASIC, FUNDAMENTAL PROBLEM
AUTHENTICATION
SCENARIOS REQUIRING AUTHENTICATION
Scenarios
• Logging into a local computer
• Logging into a computer remotely
• Accessing web sites
Potential vulnerabilities to consider when client authenticating server
• channel between the client and the server
• server compromise
• client compromise
• social engineering
• weak passwords
WHAT YOU KNOW
CS 526
Christina Garman
WHAT YOU KNOW
USER AUTHENTICATION
THREATS TO PASSWORDS
Online guessing attempts
Offline dictionary attacks
Login spoofing
Shoulder surfing
Social engineering
• e.g., pretexting: creating and using an invented scenario (the pretext) to
persuade a target to release information or perform an action and is usually
done over the telephone
THREATS TO PASSWORDS
Phishing, web-site forgery
Eavesdropping
Malware
• Keystroke logging: Covertly tracking the keys struck on a keyboard
• Defense includes anti-malware, network monitoring (to detect exfiltration),
on-screen soft keyboard, automatic form-filling, etc
Server-side insiders
• System administrators at your online bank
• Defense includes zero-knowledge authentication
PASSWORD SCHEMES
What do we need our password systems to be able to do?
• Set a password
• Log a user in
• Recover/reset a forgotten password
STORING PASSWORD DATA
We want certain properties when we store password data
• “Correctness”
• “Security”
So how should we store passwords?
ATTEMPT 1
Store the passwords in plaintext
Server simply stores a mapping of user to password in some file on
the system
Does this work?
ATTEMPT 2
Store the passwords encrypted with the server’s secret key
Server generates a key and instead of storing the password, stores
𝐸𝑛𝑐𝐾(𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) on the system
Does this work?
ATTEMPT 3
Hash the password on the server
Instead of storing password, store 𝐻(𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) for each user
Does this work?
“OFFLINE” DICTIONARY ATTACK
Passwords are not chosen at random from a large set! Passwords
are typically chosen from a very small set.
Attacker can precompute a large dictionary of 𝑤, 𝐻(𝑤) for many
common user passwords
When a password database is stolen, compare 𝐻(𝑝) ? = 𝐻(𝑤)
Rainbow tables
RAINBOW TABLES
Compromise between a lookup table and memory usage
“Reduction function”
• hash function maps plaintext into hashes
• reduction function reduces the hashes to plaintexts
Once a Rainbow Table has been created, the results can be stored,
indexed, and searched
ATTEMPT 3
Hash the password on the server
Instead of storing password, store 𝐻(𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) for each user
Does this work?
… ATTEMPT 4 …
Salt the hash function
Instead of storing 𝐻(𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑), store random salt 𝑆 and
𝐻(𝑆 || 𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) for each user
Does this work?
“ONLINE” DICTIONARY ATTACK
For each pair < 𝑆, 𝐻(𝑆 || 𝑝) > discovered in the password database,
attacker must compute 𝑤, 𝐻(𝑆 || 𝑤) for many common user
passwords
Compare 𝐻(𝑆 || 𝑝) ? = 𝐻(𝑆 || 𝑤)
By design, hash functions are very fast though…
… ATTEMPT 4 …
Salt the hash function
Instead of storing 𝐻(𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑), store random salt 𝑆 and
𝐻(𝑆 || 𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) for each user
Does this work?
… AND FINALLY ATTEMPT 5
Many iterations of the hash function
• Instead of using a traditional “fast” hash function, use a “slow” hash function
• Define 𝐻′(𝑥) = 𝐻(𝐻(𝐻(… 𝐻(𝑥)))) = 𝐻𝑘(𝑥) with 𝑥 = 𝑠𝑎𝑙𝑡 || 𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑
Store random salt 𝑆 and 𝐻′(𝑆 || 𝑝𝑎𝑠𝑠𝑤𝑜𝑟𝑑) for each user
Memory hard hash functions
MEMORY HARD HASH FUNCTIONS
Idea:
• Start with an underlying hash function ℎ
• Build a bigger hash function 𝐻 from ℎ
Assume to compute ℎ(𝑥1, … , 𝑥ℓ) requires ℓ units of time and ℓ units of
memory
Scrypt, Argon2d/Argon2i, PBKDF2
Password hashing competition!
[Link]
STORING PASSWORDS IN LINUX
THOUGHT EXPERIMENT: DO WE NEED
GOOD PASSWORDS?
THOUGHT EXPERIMENT: DO WE NEED
GOOD PASSWORDS?
THOUGHT EXPERIMENT: DO WE NEED
GOOD PASSWORDS?
THOUGHT EXPERIMENT: DO WE NEED
GOOD PASSWORDS?
THOUGHT EXPERIMENT: DO WE NEED
GOOD PASSWORDS?
PASSWORDS AND COMPUTER SECURITY
GARY MCKINNON
OLD PASSWORD SURVEYS
ROCKYOU HACK (2009)
PASSWORDS IN ROCKYOU DATABASE
GAWKER PASSWORDS (2010)
YAHOO
PASSWORD MANAGERS
Software application designed to store and manage online credentials
Can also generate passwords
Passwords are typically stored in an encrypted database and “locked”
behind a master password
Ex. 1Password, KeePass, LastPass
WHAT YOU HAVE
CS 526
Christina Garman
WHAT YOU HAVE
MAGNETIC STRIPE CARDS
MAGNETIC STRIPE CARD SECURITY
SMART CARDS
SMART CARD AUTHENTICATION
EMV AND CHIP&PIN
CONTACTLESS SMART CARDS
SIM CARDS
SIM CARD SECURITY
GSM CHALLENGE-RESPONSE PROTOCOL
RFIDS
RFID TECHNOLOGY
RFID TECHNOLOGY
RFID TECHNOLOGY
PASSPORTS
PASSPORT SECURITY
TOKENS
Either hardware (e.g. a key fob) or software (a soft token) which
creates an authentication code at fixed intervals using a built-in clock
and the card's factory-encoded (almost) random key (known as the
“seed”)
WHAT CAN GO WRONG?
We have to develop a physical object that is
• Hard to forge
• Hard to tamper with or reverse engineer
An attacker with physical access to a token must not be able to
extract the seed
WHAT YOU ARE
CS 526
Christina Garman
WHAT YOU ARE
BIOMETRICS
REQUIREMENTS FOR BIOMETRIC
IDENTIFICATION
BIOMETRIC IDENTIFICATION
CANDIDATES FOR BIOMETRIC IDS
WHAT CAN GO WRONG?
Potentially easy to forge
Privacy concerns
Very hard to revoke!
TWO FACTOR
AUTHENTICATION
CS 526
Christina Garman
TWO FACTOR AUTHENTICATION (2FA)
Usually combines something you know with something you have
• Ex. password and secure token