[ Security ] Ch07. User Authentication Mechanisms

Authentication: Who are you?

• Definition: The process by which the identity of someone or something gets established.
• Identifies a user or a resource
• Establishes trust before communication can take place
• The process of confirming an individual’s identity, either by verification or by identification
  • A person recognizing a person
  • Access control (PC, ATM, mobile phone)
  • Physical access control (house, building, area)
  • Identification (passport, driving license)

Verification vs. Identification

• Verification
  • “Is the claimant(요청하는 사람) the person who he or she claims to be?”.
  • one-to-one comparison
• Identification
  • “Is the claimant an enrolled user and who is he/she?”.
  • one-to-many comparison

Authentication Methods

• Knowledge: “something you know”
  • such as password, PIN
• Token: “something you have”
  • such as smart card, magnetic card, key, passport, USB token
• Biometrics: “something you are”
  • A physiological characteristic (such as fingerprint, iris pattern, form of hand)
  • A behavioral characteristic (such as the way you sign, the way you speak)

---

Password based authentication

→ Knowledge

Clear-Text Password

• Problems of clear-text password
  • Database contains passwords in clear text
    → store password in encrypted form
  • Password travels in clear text from the user’s computer to the server
    → send password in encrypted form

Message Digests of Passwords

• Original clear text password is never stored and transmitted
• Message digest of passwords is stored in the database, and the same is used for authentication
• Can lead to replay attacks
  • Replay attacks: resend a few times

How to Solve Replay Attack

• Each message must have an extra information such as message
  number
• If the receiver receives a duplicated message, it is discarded
• This will solve it in TCP/IP (layers 3 & 4). It has this feature to solve
  this problem

Rewrite Attacks

• If an hacker knows the contents, he/she can modify the encrypted message.

Password-Guessing Attacks

• Types
  • On-line attack
    • The system itself is used to determine whether guesses are right.
  • Off-line attack
    • Some other method is used to verify the correctness of a guess (not the system itself).
    • The form of attack will depend on how passwords are stored.
• Prevention of on-line attack
  • Slow down the rate of guessing
    • As the number of wrong guesses increases, the time delay between two consecutive tries increases.
  • Allow only a limited number of guesses
    • e.g., three wrong guess will lockup online banking service.

Encrypted Passwords

• User (client) establishes SSL connection with the server.
• All information including passwords is now encrypted by SSL.
• The passwords are also stored in encrypted form on server’s database.
  • The password file must not be readable.
  • At first, Unix system was implemented with a password file contained actual password.

Protecting Password Files

• Cryptographic protection.
  • One way encryption algorithms. This doesn’t prevent dictionary attacks.
  • Proper choice of encryption may slow down dictionary attacks (e.g., crypt())
• Access control enforced by the OS.
  • Unix and Linux store passwords in so called shadow password files (separate from /etc/passwd, usually in /etc/shadow).
  • Nobody except root can see passwd file.
  • NT stores encrypted passwords in proprietary binary formatted file (security by obscurity).

• Duplicate passwords could be a problem.
• Password Salting:
  • When storing the encrypted password, append something to it
  • Same passwords will have ‘different’ encryptions.
  • Slows down dictionary attacks.
  • To ensure that an attacker would be forced to crack each password independently as opposed to being able to target the entire password database simultaneously

Password: Hashing and Salting

• Hashing the password
• Salting the password

Linux Password File

• /etc/shadow

---

Authentication token

• A small device that generates a new random value every time it is used
  • Processor
  • LCD to show output
  • Keypad (Optional)
  • Real-time clock (Optional)
• Types
  • Challenge/response
  • Time-based

• Token and server are synchronized initially
• Token generates fresh passwords periodically
• Same passwords are generated at the server

• Creation of token
  • The corresponding seed is generated whenever an authentication token is
    generated.
• Use of token
  • An authentication token automatically generates pseudorandom numbers, called as one-time passwords & submit [ id / password ] pair to the server.
  • The server obtains the seed corresponding to the user ID from the database, and compute password using ‘Password validation program’.
  • The authentication token is protected by password or PIN.
    (You need ‘something you know’ and ‘something you have’.)
• The server returns an appropriate message back to the user.

One-Time Password

• Two entification techniquesre combined.
• A good example of this type of authentication is the use of an ATM card with a N (personal identification number)
• First approach
  • The user and the system agree upon a list of passwords.
• Second approach
  • The user and the system agree to sequentially update the password
    → P$_0$ - P$_1$ - P$_2$ ...
• Third approach
  • The user and the system create a sequentially updated password using a hash function. → Lamport one-time password
• Lamport one-time password

Challenge/Response Tokens

• Client sends login request with user ID only
• If user ID is valid, server sends a random challenge r to user
  (perhaps plain text)
• Token accepts r and creates a response (or one-time password) which is encrypted by seed, and sends it to server.
• Server verifies encrypted password.

Time-based Tokens

• Client: Token uses [seed + current sys time] to generate a password
• Server need not send any random challenge to the user.
  The time is used as a variable input to authentication process, in place of random challenge.
• Server uses same process to verify password
• User resolves time-window problems by advancing its time (1 min, 2 min, … ) until successful.

Challenge-Response

• In password authentication, the claimant proves his identity by demonstrating that he knows a secret, the password.
• In challenge-response authentication, the claimant proves that he knows a secret without sending it.
• The challenge is a time-varying value sent by the verifier; the response is the result of a function applied on the challenge.

Using an Asymmetric-Key Cipher

• Unidirectional asymmetric-key authentication
  • Bob encrypts the challenge using Alice’s public key. Alice decrypts the challenge (nonce) with her private key and sends the response (the same nonce) to Bob
• Bidirectional asymmetric-key authentication
  • Two public keys are used, one in each direction.
  • Alice sends her ID and nonce encrypted with Bob’s public key. Bob responds with his nonce encrypted with Alice’s Public key. Finally, Alice responds with Bob’s decrypted nonce

Using Digital Signature

• Digital signature, bidirectional authentication
  • Alice and Bob authenticate each other using signatures

Zero-Knowledge Proof

→ 개념정도만

• In zero-knowledge authentication, the claimant does not reveal anything that might endanger the confidentiality of the secret.
• The claimant proves to the verifier that he knows a secret, without revealing it.
• The interactions are so designed that they cannot lead to revealing or guessing the secret.
• Zero-knowledge authentication is a more sophisticated type of challenge-response authentication methods
• Interactive Zero-Knowledge Proof System

---

Certificate based authentication

• Based on the digital certificate of the user.
• CA distributes the certificates to the users also
• Validation between the two takes place at the time of authentication
• At the time of login, the user sends her certificate to the server.
• Server verifies that the certificate is a valid one.
  → Trudy may have copy of Alice’s certificate and pretends that she isAlice.

• User sends login request with user ID only
• If user ID is valid, server sends a random challenge r to user
  (perhaps plain text)
• User signs r with her private key, s=E$_{Duser}$(r)
  • Private key is accessed only through password. You need ‘something youknow’ and ‘something you have’.
• Server authenticates by comparing r1=D$_{Puser}$(s) with r.

• Step 1: User’s computer encrypts the random challenge with the user’s private key
  to produce the digital signature.
• Step 2: User’s computer sends the digital signature to the server as a part of the login request.

---

Kerberos

In Greek mythology, a many headed dog, the guardian of the entrance of Hades

Motivation

• Dedicated personal computer with no network connection
  → Security by isolation
• Centralized time sharing system
  → OS provide the security
• Distributed architecture consisting of dedicated user workstation(clients) and distributed or centralized servers
  → The issue

The Problem

• In an open distributed environment, users at workstations wish toaccess services on servers, who want to restrict access to authorizedusers by authenticating requests for service.
• A workstation cannot be trusted to identify its users correctly tonetwork services.
  • Network services: Printer, mail server, file server

Threats

• Possible threats in an open distributed environment
  • A user may gain access to a WS and pretend to be another user
  • A user may alter the network address of a WS so requests appear to comefrom a different WS
  • A user may eavesdrop on exchanges and use a replay attack to gain entranceto a server

What is Kerberos?

• Network authentication protocol
  • Provide authentication between any pair of entities.
• Developed at MIT in the mid 1980’s
• Two versions: version 4 and 5
• Design goals and decisions
  • No clear text password on the network
    • Protect against intercept
  • Limited authentication lifetime by using timestamps
    • Protect against replay attack
  • Relies on conventional encryption
    • DES (ver. 4), Other than DES (ver. 5)
  • Use a centralized server for key distribution
    • AS (authentication server) and TGS (ticket granting server)

Simple Authentication

• Challenge / response authentication
  : Substantial burden on the server in an open environment
  → Use authentication server (AS) instead.

First Scenario

→ Kerberos X

• Problems
  • Plaintext transmission of the password
  • Ticket is not reusable
    • User should enter a password and get a ticket every time for every differentservice
    • Even though the ticket is reusable, a user would need a new ticket for everydifferent service.
    • Can be resolved by ticket reuse

→ Introducing a Ticket-Granting Server (TGS)

Second Scenario

• We introduced TGS
• Ticket$_{tgs}$ is saved by the client in the user workstation.
• Each time user requires access to a new service, the client present
  Ticket$_{tgs}$ (to authenticate itself) to TGS.
• The TGS then grants a ticket Ticket$_v$ for the particular service
• Double encryption in message#2 (i.e., E$_{Kc}$[Ticket$_{tgs}$])
  • Only TGS (not even client) can see the ticket
  • Only client can recover the ticket (because of K$_c$)

• K$_c$: secret key shared by the AS and C
  • Encryption based on user’s password.
  • When the user login to workstation using the password, the Kc is derived fromthe user’s password by the client.
  • Also the AS can derive Kc from the user’s password which is in its database
    (or AS stores Kc in its database).
  • Thus, password does not travel the network.
  • And only correct user can recover the Tickettgs.
• Timestamp and lifetime (length of ticket’s lifetime)
  → The client now has a reusable ticket and need not bother the userfor each new service request.

First Problem on Second Scenario

• The length of ticket lifetime
  • Too short: needs several tickets
  • Too long: might be used by Trudy
    • Trudy capture the Ticket$_{tgs}$
    • Alice log off
    • Trudy use Alice’s network address and Ticket$_{tgs}$ to impersonate Alice.

→ Same problem with Ticket$_v$
→ Thus, network service must be able to prove that the person using aticket is the same person to whom that ticket was issued.

Solution for the First Problem

• Let AS provide both the client and the TGS with a secret piece of information. (message#2)
  → K$_{c,tgs}$ (session key between client and TGS)
  → It is encrypted with K$_c$: only client can recover it.
  → Included in Ticket$_{tgs}$: only TGS can get it.
• Then, client sends authenticator to TGS
  Authenticator = E$_{Kc,tgs}$[ ID$_c$ || AD$_c$ || Timestamp$_3$ ]
  • ID$_c$ and AD$_c$ in authenticator coincide with the content of Ticket$_{tgs}$

→ Proves the ticket presenter is the client
→ Authenticator is used once and have very short lifetime. (which makes ticket lifetime long and reusable)

Second Problem on Second Scenario

• The client needs to authenticate server
  : What if Trudy direct the client’s message to another server and that server deny the service?
  → We need server authentication.
  After message#5 server sends another authentication message to client. Session key K$_{c,v}$ (between client and application server) is used for authentication.

Kerberos Terms

• AS (Authenticating server)
  • A kind of KDC (key distribution center)
  • Authenticates a client logon and issues a ticket (TGT) for further authentication.
• TGS (Ticket granting server)
  • A kind of KDC
  • Grants tickets (SGT) to clients, who is holding TGT, for a specific application server.
• TGT (Ticket granting ticket)
  • Contains the client’s certificate for TGS
  • Encrypted by TGS’s key
• SGT (Service granting ticket)
  • Contains the client’s certificate for a server
  • Encrypted by the server’s key

Procedure (ver. 4)

Step 1

• Authentication service exchange
  • To get ticket-granting ticket

Step 2

• Ticket-granting service exchange
  • To get session-granting ticket

Step 3

• Client/Server authentication exchange
  • Mutual authentication

HGU 전산전자공학부 고윤민 교수님의 24-2 컴퓨터 보안 수업을 듣고 작성한 포스트이며, 첨부한 모든 사진은 교수님 수업 PPT의 사진 원본에 필기를 한 수정본입니다.