Information Security

Authentication

Msc Vuong Thi Nhung

Faculty of Information Technology
Hanoi University
Sept 06, 2015
Outline
 Authentication factors
 User authentication
 Password authentication, salt

 OTP

 Biometrics

 Token-based authentication

 Server-Client Authentication
 Challenge Response Authentication
 Authentication in distributed systems (multi service
providers/domains)
 Single sign-on, Microsoft Passport

 Trusted Intermediaries
 Scenario 1

ISP D
ISP B FIT E-learning
Hello FIT, I’m V

ISP C
ISP A

Student V Client
authentication
Scenario 2

ISP D
ISP B FIT E-learning

ISP C
ISP A

Hello V, I’m FIT

Student V Server
authentication
Human Authentication Factors

 What you know

 Password, Personal Identification Number (PIN)
 What you have
 USB, Email, Mobile phone, Smart Card
 What you are
 Fingerprint, Face, Hand, Eye, Voice, Typing Style
N-Factor Authentication

 Combine authentication factors to form

multiple factor authentication
 Example: OTP + username/password,
PIN + digital signature,
Outline
 Authentication factors
 User authentication
 Password authentication, salt
 OTP
 Biometrics
 Token-based authentication
 Server-Client Authentication
 Authentication in distributed systems (multi
service providers/domains)
What you know: Password

 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
exrygbzyf
kgnosfix
hash function ggjoklbsz
…
…
Basic password scheme

 Hash function h(password)  strings

 Given h(password), hard to find password
 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
 Password file is publicly readable
 Other information in password file …
 Any user can try “dictionary attack”
 User looks at password file
 Computes hash(word) for every word in dictionary
 “Salt” makes dictionary attack harder
Salted password

 To Store a Password and Salt:

 Generate a long random salt
 Prepend the salt to the password and hash it
with a standard cryptographic hash function
such as SHA-2.
 Save both the salt and the hash in the user's
database record.
Salted Password (continued)
 To Validate a Password
 Retrieve the user's salt and hash from the
database.
 Prepend the salt to the given password and
hash it using the same hash function.
 Compare the hash of the given password with
the hash from the database.
 If they match, the password is correct.
Otherwise, the password is incorrect.
Outline
 User authentication
 Password authentication, salt
 One-Time Password (OTP)
 Biometrics
 Token-based authentication
 Server-Client Authentication
 Authentication in distributed systems
What you know: One Time Password

 A one-time password (OTP) is a password

that is valid for only one login session or
transaction, on a computer system or other
digital device, valid in a short time.
 OTP can be generated based on:
 Mathematical algorithms based on a previous one
 Time-synchronization between server and client
 Challenge/response
Time-synchronized OTP

 In these OTP systems, the generation of new

passwords is based on the current time rather
than, or in addition to, the previous password or
a secret key
 This token may be a proprietary device, or a
mobile phone
 An example of time-synchronized OTP
standard is Time-based One-time Password
Algorithm (TOTP)
Mathematical algorithms based on a
previous OTP
 Each new OTP may be created from the past OTPs,
using a one-way function (call it f).
 This one-time password system works as follows:
 A seed (starting value) s is chosen.

 A hash function f(s) is applied repeatedly (for example,

1000 times) to this value. The first value, f1000(s), is

stored on the target system.
 The user's first login uses a OTP p derived by applying
f 999 times to the seed, that is, f999(s).
 The next login, must be accompanied by f998(s).

 ………… and the likes

 Challenge/Response OTP
Username/ID
challenge Server
Pass phrase +
challenge OTP OTP response
Token OTP

User provides login name

System sends challenge
User enters challenge into device
Device responds with an appropriate OTP
User enters response & password
System validates response & password
OTP devices
 Mobile phone (SMS  Token devices
OTP)
SMS OTP: Example
Outline
 User authentication
 Password authentication, salt
 One-Time Password (OTP)
 Biometrics
 Token-based authentication
 Server-Client Authentication
 Authentication in distributed systems
“What You Are”: Biometrics
 Fingerprint Biometrics
“The automated use of
 55% of market physiological or behavioral
 Face characteristics to determine
or verify identity.”
 17% of market – International Biometrics Group
 Hand
 12% of market
 Eye (Iris/Retina)
 7% of market
 Voice
 5% of market
 Keyboarding
 <1% of market
Outline
 User authentication
 What you know: Password authentication, salt
 What you know: One-Time Password (OTP)
 What you are: Biometrics
 What you have: Token-based authentication
 Authentication in distributed systems (multi
service providers/domains)
 Single sign-on, Microsoft Passport
 Trusted Intermediaries
What you have: Smart Card

 To authenticate to a
computer or over a remote
access connection, the user
inserts the smart card into a
suitable reader and enters
the PIN.
 The user cannot gain access
with just the PIN, or with just
the smart card.
 Token-based Authentication: Smart Card
 With embedded CPU and memory
 Various forms
 PIN protected memory card
 Enter PIN to get the password
 Cryptographic challenge/response cards
 A cryptographic key in memory
 Computer create a random challenge
 Enter PIN to encrypt/decrypt the challenge w/ the card
 Cryptographic Calculator (readerless smart card)
 Simulating a smartcard: user enter the encrypted result
What you have: Email/Mobile phone

 Server create random number N

 Server sends N to user’s email/cellphones
 User verify the number via website
Outline
 User authentication
 Password authentication, salt
 Challenge-Response
 Biometrics
 Token-based authentication
 Server-Client Authentication
 Challenge Handshake Authentication (CHAP)
 Authentication in distributed systems
 Single sign-on, Microsoft Passport
 Trusted Intermediaries
Challenge Handshake Authentication
Protocol（CHAP）

Client c Server
Login ,IDc

IDc, R

MAC=H(R,K)
IDc, MAC
MAC’=H(R,K)
OK / Disconnect
Compare MAC’ with
MAC
CHAP Examples

 Point to Point Protocol (PPP)

 Dial up
 PPPoE
 ADSL Modem
 PPTP
 Hanu Dormitory Internet
PPP CHAP EXAMPLE
Step 1
Step 2
Step 3
Step 4
Step 5
 Step 6

http://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-ppp/25647-understanding-
ppp-chap.html
Outline
 Authentication factors
 User authentication
 Password authentication, salt
 Challenge-Response
 Biometrics
 Token-based authentication
 Server-Client Authentication
 Challenge Handshake Authentication (CHAP)
 Authentication in distributed systems
 Single sign-on: Microsoft Passport
 Trusted Intermediaries
Idea of SSO
Example of SSO: Google
How to build SSO?
Outline
 User authentication
 Password authentication, salt
 Challenge-Response
 Biometrics
 Token-based authentication
 Server-Client Authentication
 Challenge Handshake Authentication (CHAP)
 Authentication in distributed systems
 Single sign-on, Microsoft Passport
 Trusted Intermediaries
Trusted Intermediaries

Symmetric key problem: Public key problem:

 How do two entities  When Alice obtains
establish shared secret key Bob’s public key (from
over network? web site, e-mail,
Solution: diskette), how does she
know it is Bob’s public
 trusted key distribution key, not Trudy’s?
center (KDC) acting as
intermediary between Solution:
entities  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
KX-KDC
KP-KDC KB-KDC
KY-KDC

KZ-KDC
KA-KDC KB-KDC
Key Distribution Center (KDC)
Q: How does KDC allow Bob, Alice to determine shared
symmetric secret key to communicate with each other?

KDC
generates
KA-KDC(A,B) R1

Alice KA-KDC(R1, KB-KDC(A,R1) ) Bob knows to

knows use R1 to
R1 KB-KDC(A,R1) communicate
with Alice

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
 Designed to authenticate users accessing network
servers
 Used in Telnet (for remote login) and NFS (for
access to remote files)
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 E’s public key digitally signed by CA –
CA says “this is E’s public key”

Bob’s digital
+
public +
signature KB
key KB (encrypt)
CA
certificate for
K-
Bob’s private
identifying key CA Bob’s public key,
information signed by CA
Certification Authorities
 When Alice wants Bob’s public key:
 gets Bob’s certificate (Bob or elsewhere).
 apply CA’s public key to Bob’s certificate, get Bob’s
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.
+ digital Bob’s
KB signature public
+
(decrypt) KB key

CA
public +
K CA
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
Tutorial

 Register for your Certificate

 Use your Certificate to sign/encrypt email