Outline
User authentication
Password authentication, salt
Challenge-response authentication protocols
Biometrics
Token-based authentication
Authentication in distributed systems (multi
service providers/domains)
Single sign-on, Microsoft Passport
Trusted Intermediaries
Password authentication
Basic idea
User has a secret password
System checks password to authenticate user
Issues
How is password stored?
How does system check password?
How easy is it to guess a password?
Difficult to keep password file secret, so best if it is hard to
guess password even if you have the password file
Basic password scheme
User
Password file
kiwifruit
hash function
exrygbzyf
kgnosfix
ggjoklbsz
Basic password scheme
Hash function h : strings strings
Given h(password), hard to find password
No known algorithm better than trial and error
User password stored as h(password)
When user enters password
System computes h(password)
Compares with entry in password file
No passwords stored on disk
Unix password system
Hash function is 25xDES
25 rounds of DES-variant encryptions
Any user can try dictionary attack
Salt makes dictionary attack harder
R.H. Morris and K. Thompson, Password security: a
case history, Communications of the ACM, November
1979
Salt
Password line
walt:fURfuu4.4hY0U:129:129:Belgers:/home/walt:/bin/csh
Compare
Input
Salt
Key
Constant,
A 64-bit block of 0
25x DES
Ciphertext
Plaintext
When password is set, salt is chosen randomly
12-bit salt slows dictionary attack by factor of 212
Dictionary Attack some numbers
Typical password dictionary
1,000,000 entries of common passwords
people's names, common pet names, and ordinary words.
Suppose you generate and analyze 10 guesses per second
This may be reasonable for a web site; offline is much faster
Dictionary attack in at most 100,000 seconds = 28 hours, or 14 hours
on average
If passwords were random
Assume six-character password
Upper- and lowercase letters, digits, 32 punctuation characters
689,869,781,056 password combinations.
Exhaustive search requires 1,093 years on average
Outline
User authentication
Password authentication, salt
Challenge-response authentication protocols
Biometrics
Token-based authentication
Authentication in distributed systems (multi
service providers/domains)
Single sign-on, Microsoft Passport
Trusted Intermediaries
Challenge-response Authentication
Goal: Bob wants Alice to prove her identity to
him
Protocol ap1.0: Alice says I am Alice
I am Alice
Failure scenario??
Authentication
Goal: Bob wants Alice to prove her identity to
him
Protocol ap1.0: Alice says I am Alice
I am Alice
in a network,
Bob can not see
Alice, so Trudy simply
declares
herself to be Alice
Authentication: another try
Protocol ap2.0: Alice says I am Alice in an IP packet
containing her source IP address
Alices
I am Alice
IP address
Failure scenario??
Authentication: another try
Protocol ap2.0: Alice says I am Alice in an IP packet
containing her source IP address
Alices
IP address
Trudy can create
a packet
spoofing
I am Alice
Alices address
Authentication: another try
Protocol ap3.0: Alice says I am Alice and sends her
secret password to prove it.
Alices
Alices
Im Alice
IP addr password
Alices
IP addr
OK
Failure scenario??
Authentication: another try
Protocol ap3.0: Alice says I am Alice and sends her
secret password to prove it.
Alices
Alices
Im Alice
IP addr password
Alices
IP addr
OK
playback attack: Trudy
records Alices packet
and later
plays it back to Bob
Alices
Alices
Im Alice
IP addr password
Authentication: yet another try
Protocol ap3.1: Alice says I am Alice and sends her
encrypted secret password to prove it.
Alices encrypted
Im Alice
IP addr password
Alices
IP addr
OK
Failure scenario??
Authentication: another try
Protocol ap3.1: Alice says I am Alice and sends her
encrypted secret password to prove it.
Alices encryppted
Im Alice
IP addr password
Alices
IP addr
OK
Alices encrypted
Im Alice
IP addr password
record
and
playback
still works!
Authentication: yet another try
Goal: avoid playback attack
Nonce: number (R) used only once in-a-lifetime
ap4.0: to prove Alice live, Bob sends Alice nonce, R.
Alice
must return R, encrypted with shared secret key
I am Alice
R
KA-B(R)
Failures, drawbacks?
Alice is live, and
only Alice knows
key to encrypt
nonce, so it must
be Alice!
Authentication: ap5.0
ap4.0 doesnt protect against server database reading
can we authenticate using public key techniques?
ap5.0: use nonce, public key cryptography
I am Alice
R
K A (R)
Bob computes
+ -
KA(KA (R)) = R
and knows only Alice
could have the private
key, that encrypted R
such that
+ K (K (R)) = R
A A
Outline
User authentication
Password authentication, salt
Challenge-response authentication protocols
Biometrics
Token-based authentication
Authentication in distributed systems (multi
service providers/domains)
Single sign-on, Microsoft Passport
Trusted Intermediaries
Biometrics
Use a persons physical characteristics
fingerprint, voice, face, keyboard timing,
Advantages
Cannot be disclosed, lost, forgotten
Disadvantages
Cost, installation, maintenance
Reliability of comparison algorithms
False positive: Allow access to unauthorized person
False negative: Disallow access to authorized person
Privacy?
If forged, how do you revoke?
Biometrics
Common uses
Specialized situations, physical security
Combine
Multiple biometrics
Biometric and PIN
Biometric and token
Token-based Authentication
Smart Card
With embedded CPU and memory
Carries conversation w/ a small card reader
Various forms
PIN protected memory card
Enter PIN to get the password
Cryptographic challenge/response cards
Computer create a random challenge
Enter PIN to encrypt/decrypt the challenge w/ the card
Smart Card Example
Initial data (PIN)
Time Challenge
function
Some complications
Initial data (PIN) shared with server
Need to set this up securely
Shared database for many sites
Clock skew
Time
Outline
User authentication
Password authentication, salt
Challenge-Response
Biometrics
Token-based authentication
Authentication in distributed systems
Single sign-on, Microsoft Passport
Trusted Intermediaries
Single sign-on systems
e.g. Securant, Netegrity,
LAN
Rules
user name,
password,
other auth
Authentication
Database
Application
Server
Advantages
User signs on once
No need for authentication at multiple sites, applications
Can set central authorization policy for the enterprise
Microsoft Passport
Launched 1999
Claim > 200 million accounts in 2002
Over 3.5 billion authentications each month
Log in to many websites using one account
Used by MS services Hotmail, MSN Messenger or
MSN subscriptions; also Radio Shack, etc.
Hotmail or MSN users automatically have
Microsoft Passport accounts set up
Passport log-in
Trusted Intermediaries
Symmetric key problem:
Public key problem:
How do two entities
establish shared secret
key over network?
When Alice obtains
Bobs public key (from
web site, e-mail,
diskette), how does she
know it is Bobs public
key, not Trudys?
Solution:
trusted key distribution
center (KDC) acting as
intermediary between
entities
Solution:
trusted certification
authority (CA)
Key Distribution Center (KDC)
Alice, Bob need shared symmetric key.
KDC: server shares different secret key with each
registered user (many users)
Alice, Bob know own symmetric keys, KA-KDC KB-KDC , for
communicating with KDC.
KDC
KA-KDC KP-KDC
KP-KDC
KB-KDC
KA-KDC
KX-KDC
KY-KDC
KB-KDC
KZ-KDC
Key Distribution Center (KDC)
Q: How does KDC allow Bob, Alice to determine shared
symmetric secret key to communicate with each other?
Alice and Bob communicate: using R1 as
session key for shared symmetric encryption
Ticket and Standard Using KDC
Ticket
In KA-KDC(R1, KB-KDC(A,R1) ), the KB-KDC(A,R1) is also
known as a ticket
Comes with expiration time
KDC used in Kerberos: standard for shared key
based authentication
Users register passwords
Shared key derived from the password
Kerberos
Trusted key server system from MIT
one of the best known and most widely implemented
trusted third party key distribution systems.
Provides centralised private-key third-party
authentication in a distributed network
allows users access to services distributed through
network
without needing to trust all workstations
rather all trust a central authentication server
Two versions in use: 4 & 5
Widely used
Red Hat 7.2 and Windows Server 2003 or higher
Kerberos 4 Overview
Kerberos Realms
A Kerberos environment consists of:
a Kerberos server
a number of clients, all registered with server
application servers, sharing keys with server
This is termed a realm
typically a single administrative domain
If have multiple realms, their Kerberos
servers must share keys and trust
When NOT Use Kerberos
No quick solution exists for migrating user
passwords from a standard UNIX password
database to a Kerberos password database
such as /etc/passwd or /etc/shadow
For an application to use Kerberos, its source must
be modified to make the appropriate calls into the
Kerberos libraries
Kerberos assumes that you are using trusted hosts
on an untrusted network
All-or-nothing proposition
If any services that transmit plaintext passwords remain
in use, passwords can still be compromised
Certification Authorities
Certification authority (CA): binds public key to
particular entity, E.
E (person, router) registers its public key with CA.
E provides proof of identity to CA.
CA creates certificate binding E to its public key.
Certificate containing Es public key digitally signed by CA
CA says this is Es public key
Bobs
public
key
Bobs
identifying
information
KB
digital
signature
(encrypt)
CA
private
key
K-
CA
KB
certificate for
Bobs public key,
signed by CA
Certification Authorities
When Alice wants Bobs public key:
gets Bobs certificate (Bob or elsewhere).
apply CAs public key to Bobs certificate, get Bobs
public key
CA is heart of the X.509 standard used extensively in
SSL (Secure Socket Layer), S/MIME (Secure/Multiple Purpose
Internet Mail Extension), and IP Sec, etc.
+
KB
digital
signature
(decrypt)
CA
public
key
+
K CA
Bobs
public
+
K B key
Single KDC/CA
Problems
Single administration trusted by all principals
Single point of failure
Scalability
Solutions: break into multiple domains
Each domain has a trusted administration
Multiple KDC/CA Domains
Secret keys:
KDCs share pairwise key
topology of KDC: tree with shortcuts
Public keys:
cross-certification of CAs
example: Alice with CAA, Boris with CAB
Alice gets CABs certificate (public key p1), signed by CAA
Alice gets Boris certificate (its public key p2), signed by
CAB (p1)
Key Distribution Center (KDC)
Q: How does KDC allow Bob, Alice to determine shared
symmetric secret key to communicate with each other?
KDC
generates
R1
KA-KDC(A,B)
Alice
knows
R1
KA-KDC(R1, KB-KDC(A,R1) )
KB-KDC(A,R1)
Bob knows to
use R1 to
communicate
with Alice
Alice and Bob communicate: using R1 as
session key for shared symmetric encryption
Consider the KDC and CA servers.
Suppose a KDC goes down. What is
the impact on the ability of parties
to communicate securely; that is,
who can and cannot communicate?
Justify your answer. Suppose now a
CA goes down. What is the impact
of this failure?
Backup Slides
Advantages of salt
Without salt
Same hash functions on all machines
Compute hash of all common strings once
Compare hash file with all known password files
With salt
One password hashed 212 different ways
Precompute hash file?
Need much larger file to cover all common strings
Dictionary attack on known password file
For each salt found in file, try all common strings
Four parts of Passport account
Passport Unique Identifier (PUID)
Assigned to the user when he or she sets up the account
User profile, required to set up account
Phone number or Hotmail or MSN.com e-mail address
Also name, ZIP code, state, or country,
Credential information
Minimum six-character password or PIN
Four-digit security key, used for a second level of
authentication on sites requiring stronger sign-in credentials
Wallet
Passport-based application at passport.com domain
E-commerce sites with Express Purchase function use wallet
information rather than prompt the user to type in data
