Authentication systems. Authentication methodologies

Transcription

1 Authentication systems Diana Berbecaru < polito.it > Politecnico i di Torino Dip. Automatica e Informatica Authentication methodologies can be based on different factors ( 1/2/3-factors authentication ): something I know pippo! (e.g. a password) something I have (e.g. magnetic card) something I am (e.g. my fingerprint) multiple different mechanisms can be combined to achieve identification 1

2 User authentication server authentication ti ti request UID user (UID) UID : f (S UID ) proof request proof = F (S UID ) secret (S UID ) Password-based authentication secret = the user password F = I (the identity function) case #1: f = I access control: proof = password? case #2: f = one-way hash function H access control: F(proof) = F(S UID )? 2

3 Password-based authentication: case#1 server UID : S UID authentication ti ti request UID proof request proof = S UID user (UID) secret (S UID ) checks if indeed proof = password (= S UID ) Password-based authentication: case#2 server authentication ti ti request UID user (UID) UID : H(S UID ) checks if indeed proof = H(S UID ) proof request proof = H(S UID ) secret (S UID ) computes proof = H(S UID ) 3

4 pro: Password-based authentication simple for the user cons: password storage (post-it!) password readable during transmission password guessable (my son s name!) the server must know in cleartext the password or its digest unprotected (dictionary attack) possible attacks: sniffing and replay Password suggestions to reduce the associated risks: letters + digits + special characters long (at least 8 characters) never use dictionary words 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 4

5 (Symmetric) challenge-response systems user proves its identity to verifier by demonstrating knowledge of a secret without revealing the (shared) secret itself to the verifier during the protocol sniffing of 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 secret and the challenge the challenge is usually time variant and is random number. (Symmetric) challenge-response systems the challenge must be different every time: even if the adversary is monitoring the network he won t be able to reuse the response replay attack not possible the server must know the secret in clear often R is a hash function UID user challenge response = R (challenge, S UID ) { UID, S UID } S UID 5

6 Symmetric challenge-response systems server UID : S UID authentication ti ti request UID proof request + challenge proof user (UID) secret (S UID ) checks if indeed proof = H(challenge,S UID ) computes proof = H(challenge, S UID ) Mutual authentication with symmetric challenge (v1) this is the base exchange only the initiator provides explicitly its (claimed) identity A C B Alice enc (K AB, C B ) C A Bob enc (K AB, C A ) 6

7 Mutual authentication with symmetric challenge (v2) reduction in the number of messagges (better performance but no impact on security) used dby the IBMSNA A, C A Alice C B, enc (K AB, C A ) Bob enc (K AB, C B ) Attack to the symmetric challenge protocol Mike (as Alice) A, S A Bob S B, enc (K AB, S A ) conn n #1 S B enc #2 conn A, S B S C, enc (K AB, S B ) enc (K AB, S B ) 7

8 (Asymmetric) challenge-response systems a random number R is encrypted with the user's public key and dthe users replies by sending Ri in clear thanks to its knowledge of the private key cert (Mario, KpubMario) user challenge = E (R, KpubMario) acceptable users response = R private key Risks with asymmetric challenges trust in the issuer CA of the user cert check of the name constraint on trusted CAs unwilling RSA signature possible: if R=digest(document)... and the server sends R in clear and ask it back encrypted with user s private key... then the user has unwillingly gysigned the document!!! 8

9 original idea: Bell Labs One-Time Passwords (OTP) the S/KEY system (RFC 1760) public-domain implementation commercial implementations with automatic hardware generators (authenticator) OTP provisioning to the users on stupid or insecure workstation: paper sheet of pre-computed passwords hardware authenticator (crypto token) on intelligent and secure workstation : automatically computed by an ad-hoc application eventual integration into the communication sw (e.g. telnet client) or hw (e.g. modem) 9

10 RFC-1760 The S/KEY system (I) the user generates a secret S (the seed) the user computes N one-time passwords: P 1 = h (S) P 2 = h (P 1 ) = h( h(s) )... the user initializes the authentication server with the last generated password (e.g. P 100 ) User Initial secret s h Password 1 h(s) h Password 2 h(h(s))=h 2 (s) *** The S/KEY system (III) User has Password n h n (s) Password n-1 h n-1 (s) Password 2 h(h(s))=h h 2 (s) h(password n-1)?= h n (s) server Password n h n (s) store Password n-1 Password n-1 h n-1 (s) Password n h(h( h(s)))=h n (s) Password generation Password 1 h(s) S/KEY authentication 10

11 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 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 the user inserts a pass phrase (PP): minimum 8 char long secret! (if disclosed then the security of S/KEY is compromised) 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) 11

12 OTP problems generally uncomfortable uncomfortable when used to access multiple password-based d services (e.g. POP with periodic check of the mailbox) expensive when based on hw authenticators paper-based passwords cannot be used by a process but only by a human operator Problems of hw authenticators denial-of-service: deliberately wrong attempts to trigger account blocking social engineering: phone call to simulate loss of the authenticator and remotely initialize a new one 12

13 Security Dynamics: SecurID time-based synchronous OTP technique: P UID ( t ) = h ( S UID, 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 SecurID: architecture the client sends in clear user, PIN, token-code (seed, time) based on user and PIN the server verifies against three possible token-codes: TC -1, TC 0, 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 13

14 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 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) 14

15 SecurID: architecture token OK? ACE server token OK? ACE client OK! KO! ACE client TELNET server DBMS server TELNET client user, PIN, TC SecurID (normal) user, TC* DBMS client SecurID (pinpad) Example RSA SecureID 15

16 ACE/client SecurID: client manages the dialogue with the ACE/server encrypted channel sd_ftp for secure FTP available for: Unix Win32 Netware Macintosh TACACS ACE/server: 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 16

17 Biometric systems measure of one biologic characteristics of the user main characteristics being used: fingerprint voice retinal scan iris scan useful to *locally* replace a PIN or a password Problems of biometric systems FAR = False Acceptance Rate FRR = False Rejection Rate FAR and FRR may be partly tuned but they heavily depend on the cost of the device variable biological characteristics: finger wound voice altered due to emotion retinal blood pattern altered due to alcohol or drug 17

18 FAR / FRR Kerberos Kerberos is a network authentication protocol system initially developed as part of MIT project Athena provides authentication for client-server applications, and data integrity and confidentiality relies entirely on symmetric cryptography two versions in use: 4 & 5 18

19 Kerberos authentication service only; 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 Kerberos Overview clients wants service from a particular server an Authentication Server (AS) allows access to the service for a particular period of time How? Based on tickets Ticket: specifies that a particular client (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: pippo@example.com 19

20 Kerberos (cont.) servers must confirm the identities of clients undertaking this task in an open environment places a significant ifi burden on server solution: use an authentication server (AS) 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 t use Kerberos as authentication ti ti system (distributed physically or in some other secure manner) Kerberos (simple authentication dialog) K S AS Authentication Server {TGT} s request client user ID, {TGT} s (application) server 20

21 Kerberos (simple authentication dialog) request: (user s ID, server s ID, user s password) AS checks its user DB: whether user supplied the correct password for this user ID 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? Kerberos (simple authentication dialog) problems: 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) 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 (T S ) every time that service is needed, use the T S mark time when tickets are issued and also lifetime of tickets. 21

22 Ticket Granting Server (TGS) New service: 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 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 Ts for a particular service Kerberos high-level view K UID, K TGS AS Authentication Server { TGT } TGT K S TGS Ticket Granting Server T s request client T s (application) server 22

23 ticket 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 MIT V4 (the original public one) MIT V5 (RFC-1510) not only DES extended ticket lifetime (begin-end) 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 23

24 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 ) specific for some applications only integral SSO: multiapplication authentication techniques (e.g. asymmetric challenge, Kerberos) likely requires a change in the applications 24