Authentication systems. Authentication methodologies. User authentication. Authentication systems (auth - april 2012)

Authentication systems

Diana Berbecaru < diana berbecaru @ polito it > < diana.berbecaru @ polito.it >

Politecnico di Torino Dip. Automatica e Informatica

Course Computer Systems Security - 2012

Authentication methodologies

( 1/2/3-factors authentication): „something I know (e.g. a password) „something I have pippo! g

(e.g. magnetic card) „something I am

(e.g. my fingerprint)

„ multiple different mechanisms can be combined to achieve identification

Course Computer Systems Security - 2012

User authentication

Password-based authentication

„ F = I (the identity function)

„ case #1: f = I

t l f d ?

„ access control: proof = password ?

„ case #2: f = one-way hash function H „ access control: F(proof) = F(SUID) ?

Course Computer Systems Security - 2012

Password-based authentication: case#1

user (UID) UID authentication request server secret (SUID) proof request proof = SUID UID : SUID checks if indeed proof = password (= SUID)

Course Computer Systems Security - 2012

Password-based authentication: case#2

user (UID) UID authentication request server secret (SUID) proof request proof = H(SUID) UID : H(SUID) checks if indeed proof = H(SUID) computes proof = H(SUID)

Password-based authentication

„simple for the user „ cons:

„password storage (post-it!)

d d bl d i t i i

„password readable during transmission „password guessable (my son’s name!)

„the server must know in cleartextthe password or its digest unprotected (dictionary attack)

„ possible attacks: sniffingand replay

Course Computer Systems Security - 2012

Password

„ suggestions to reduce the associated risks: „letters + digits + special characters

„long (at least 8 characters) „never use dictionary words

f tl h d (b t t t f tl !)

„frequently changed (but not too frequently!) „don’t use them :-)

„ use of at least one password (or PIN or access code or ...) unavoidable unless we use biometric techniques

Course Computer Systems Security - 2012

(Symmetric) challenge-response systems

knowledge of a secret withoutrevealing the (shared) secret itself to the verifier during the protocol

„sniffingof the secret not possible

„ a challenge(typically a random number) is sent to the user ...

„ ... who replies with the solution after a computation involving the shared secretand the challenge „ the challenge is usually time variant and is random

number.

(Symmetric) challenge-response systems

„replay attack not possible

„ the server must know the secret in clear „ often R is a hash function

user

UID

challenge

response = R (challenge, SUID)

{ UID, SUID} SUID

Course Computer Systems Security - 2012

Symmetric challenge-response systems

user (UID)

UID

authentication request server

secret (SUID) proof request + challenge

proof UID : SUID

checks if indeed proof = H(challenge,SUID)

computes proof = H(challenge, SUID)

Course Computer Systems Security - 2012

Mutual authentication

with symmetric challenge (v1)

„ only the initiator provides explicitly its (claimed) identity A C_B enc (K_AB , C_B) C_A enc (K_AB , C_A) Alice Bob

Mutual authentication

with symmetric challenge (v2)

performance but no impact on security) „ used by the IBM SNA

A C A , C_A

C_B , enc (K_AB , C_A)

enc (K_AB, C_B)

Alice Bob

Course Computer Systems Security - 2012

Mike (as Alice)

Attack to the symmetric challenge protocol

A , S_A S_B, enc (K_AB, S_A) Bob B , ( AB , A) enc (K_AB, S_B) A , S_B S_C , enc (K_AB , S_B) conn #1 conn #2 S_B enc

Course Computer Systems Security - 2012

(Asymmetric) challenge-response systems

public key ...

„ ... and the users replies by sending R in clear thanks to its knowledge of the private key

user

cert (Mario, KpubMario)

challenge = E (R, KpubMario) response = R

acceptable

Risks with asymmetric challenges

„ check of the name constraint on trusted CAs „ unwilling RSA signature possible:

„if R=digest(document) ...

d th d R i l d k it b k

„and the server sends R in clear and ask it back encrypted with user’s private key ...

„then the user has unwillingly signed the document!!!

Course Computer Systems Security - 2012

One-Time Passwords (OTP)

„Bell Labs

„the S/KEY system (RFC 1760) „public-domain implementation

„ commercial implementations with automatic hardware generators (authenticator)

Course Computer Systems Security - 2012

OTP provisioning to the users

„paper sheet of pre-computed passwords „hardware authenticator (crypto token) „ on intelligent and secure workstation :

t ti ll t d b d h li ti

„automatically computed by an ad-hoc application „eventual integration into the communication sw (e.g.

telnet client) or hw (e.g. modem)

The S/KEY system (I)

„ the user generates a secret S (the seed) „ the user computes N one-time passwords:

„P1= h (S)

P h (P ) h( h(S) ) „P2= h (P1) = h( h(S) ) „. . .

„ the user initializes the authentication server with the last generated password (e.g. P100)

Course Computer Systems Security - 2012

*** The S/KEY system (III)

Initial secret s Password 1 h(s) h Password n hn_(s) Password n-1 hn-1_(s) Password n hn_(s) h(Password n-1) ?= hn_(s) User has store Password n-1 server User h(s) Password 2 h(h(s))=h2_(s) Password n h(h(…h(s)))=hn_(s) h h (s) Password 2 h(h(s))=h2_(s) Password 1 h(s) Password n-1 hn-1_(s)

Password generation S/KEY authentication n 1

The S/KEY system (II)

„ the server prompts for the passwords in reverse sequence:

„S: P99? „C: X

„S: if h (X) = P100 then access allowed + X is stored „S: if h (X) = P100 then access allowed + X is stored „ in this way the server doesn’t need to know the

client’s secret

„ RFC-1760 uses MD4 (other choices possible)

„ public-domain implementation for Unix, MS-DOS, Windows, MacOs

S/KEY – generation of the password list

„minimum 8 char long

„secret! (if disclosed then the security of S/KEY is compromised)

„ PP is concatenated with a server-provided seed „ PP is concatenated with a server-provided seed

„the seed is not secret (sent in cleartext from S to C) „allows to use the same PP for multiple servers

(using different seeds) and to safely reuse the same PP by changing the seed

„ a 64 bit quantity is extracted from the MD4 hash (by XORing the first / third 32 bit groups and the second / fourth groups)

OTP problems

„ uncomfortable when used to access multiple password-based services (e.g. POP with periodic check of the mailbox)

„ expensive when based on hw authenticatorsp „ paper-based passwords cannot be used by a

process but only by a human operator

Course Computer Systems Security - 2012

Problems of hw authenticators

„deliberately wrong attempts to trigger account blocking

„ social engineering:

„phone call to simulate loss of the authenticator and „phone call to simulate loss of the authenticator and

remotely initialize a new one

Security Dynamics: SecurID

PUID( t ) = h ( SUID, t ) „ access code ( token-code ):

„8 digits

„random, never repeats itself „changes every 60 s „ maximum drift 15 s / year „ expires in 4 years

„ based on proprietary and secret (!) hash algorithm

Course Computer Systems Security - 2012

SecurID: architecture

user , PIN , token-code (seed, time)

„ based on user and PIN the server verifies against three possible token-codes:

TC-1, TC0, TC+1

„ duress code: PIN to generate an alarm (useful for

authentication under threat)

„ wrong authentication attempts limited (default: 10) „ may have three different keys per device

Course Computer Systems Security - 2012

SecurID: hardware

„ SecurID Card: classic device (credit-card size)

„ SecurID PinPad: local PIN keying and then only

user and token-code* are sent to the server

„ SecurID Key Fob: usable as a key fob

S ID d PCMCIA II V 34 d ith

„ SecurID modem: PCMCIA-II V.34 modem with an

internal token activated via sw by introducing the PIN

RSA SecurID - Token

„token available in various models, but all with the same functionality: generate tokencode

„with integrated smartcard (SID800), pinpad (SD520), software version (SoftID)Course Computer Systems Security - 2012

SecurID: architecture

ACE server

ACE client ACE client

token OK? token OK?

OK! KO! TELNET server DBMS server TELNET client SecurID (normal) DBMS client SecurID (pinpad)

user, PIN, TC user, TC*

OK! KO!

Course Computer Systems Security - 2012

Example RSA SecureID

SecurID: client

„manages the dialogue with the ACE/server „encrypted channel „sd_ftp for secure FTP il bl f „ available for: „Unix „Win32 „Netware „Macintosh „TACACS

Course Computer Systems Security - 2012

SecurID: server

„authentication with SecurID tokens „monitor, audit and report

„GUI management interface „authentication API

„SQL interface to access a DBMS (already) storing the user data

„large commercial support in security (e.g. firewall) and communication (e.g. comm. server) products „available for Solaris, AIX, HP-UX, NT, 2000, XP

Course Computer Systems Security - 2012

Biometric systems

„ measure of one biologic characteristics of the user „ main characteristics being used:

„fingerprint „voice

ti l „retinal scan „iris scan

„ useful to *locally* replace a PIN or a password

Problems of biometric systems

„ FRR= False Rejection Rate

„ FAR and FRR may be partly tuned but they heavily depend on the cost of the device

„ variable biological characteristics: „ variable biological characteristics:

„finger wound

„voice altered due to emotion

„retinal blood pattern altered due to alcohol or drug

Course Computer Systems Security - 2012

FAR / FRR

Course Computer Systems Security - 2012

Kerberos

„ Kerberos is a network authentication protocol „ system initially developed as part of MIT project

Athena

„http://web.mit.edu/kerberos/www/ „ provides authentication for client-server „ provides authentication for client-server

applications, and data integrity and confidentiality „ relies entirely on symmetric cryptography

„ two versions in use: 4 & 5

Kerberos

„ accounting and audit service were never implemented

„ applies to an open distributed environment in which users at workstations wish to access

services on servers distributed throughout the network

„ servers need to be able to restrict the access to authorized users and to authenticate requests for service

„ workstations cannot be trusted to identify its users correctly to network service

Course Computer Systems Security - 2012

Kerberos Overview

service for a particular period of time „ How ? Based on tickets

„ Ticket: specifies that a particular client ( th ti t d b th AS) h th i ht t bt i (authenticated by the AS) has the right to obtain service from a specified server S

„ Servers are able to verify the validity of tickets „ Realm:network under the control of an AS

„ Principal:is the name used to refer to the entries in the AS database

„ format: Name[/Instance]@REALM „ example: [email protected]

Kerberos (cont.)

„ servers must confirm the identities of clients „ undertaking this task in an open environment

places a significant burden on server

„ solution: use an authentication server (AS)

„ knows the password of all users (stored in a DB) „ knows the password of all users (stored in a DB) „ shares a unique secret key (e.g. s) with each

server in the Kerberos domain, that is the set of systems that use Kerberos as authentication system

„ (distributed physically or in some other secure manner)

Kerberos (simple authentication dialog)

Course Computer Systems Security - 2012

Kerberos (simple authentication dialog)

„ whether user supplied the correct password for this user ID

„ whether this user is permitted access to server „ whether this user is permitted access to server „ => AS accepts the user as authentic and must

convince the (application) server

„ creates {TGT}s: (user’s ID, network address, server’s ID) encrypted with the shared secret s „ client cannot forge {TGT}s

„ server: verifies user ID in {TGT}s = (sent) user ID ?

Course Computer Systems Security - 2012

Kerberos (simple authentication dialog)

„ user password sent in clear

„ supposing each ticket can be used only once, the user need to insert the password for each access request (e.g. to mail server, file server, etc)

l ti t t f ti k t ith t diff t

„ solution: use two type of tickets with two different

lifetimes:

„ one ticket grants to right to ask for service; performed once per login session: ticket-granting ticket (TGT)

„ for each type of service, use a ticket that grants the right to use that particular service: service-granting ticket(TS) „ every time that service is needed, use the TS

Ticket Granting Server (TGS)

„ TGS issues TGT tickets to users who have been authenticated to AS

„ AS sends to client a TGT demonstrating the user is authorized to receive a ticket for a service

l th l iti t TGT b t t

„ only the legitimate user can recover TGT but cannot alter because it is encrypted (by AS) with TGS’s secret key

„ the client module in the user workstation saves this ticket. Each time the user requires access to a new service, the client applies to the TGS, using the TGT to authenticate itself

„ based on TGT, user gets a Tsfor a particular service

Course Computer Systems Security - 2012

Kerberos high-level view

AS _TGS { TGT } TGT Authentication Server Ticket Granting Server KUID, KTGS KS client (application) server { TGT } Ts Ts request

Course Computer Systems Security - 2012

Kerberos ticket (TGT, Ts)

„data structure to authenticate a client to a server „variable lifetime

(V4: max 21 hours = 5’ x 255) (V5: unlimited)

( )

„encrypted with the DES key of the target server „bound to the IP address of the client

„bound to just one principal „ simple or mutual authentication

Kerberos versions

„not only DES

„extended ticket lifetime (begin-end) „inter-realm authentication

„inter realm authentication „forwardable ticket „message byte ordering

„ OSF-DCE (Distributed Computing Environment from Open Source Foundation)

„based on MIT V5

„implemented as RPC rather than a message exchange protocol

SSO (Single Sign-On)

„ the user has a single “credential” to authenticate himself and access any service in the system „ fictitious SSO:

„client for automatic password synchronization / management (alias “password wallet”)g ( p )

„specific for some applications only „ integral SSO:

„multiapplication authentication techniques (e.g. asymmetric challenge, Kerberos) „likely requires a change in the applications