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

Transcription

1 Authentication systems Diana Berbecaru < polito.it > Politecnico 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 User authentication UID : f (S UID ) authentication request UID proof request proof = F (S UID ) user (UID) secret (S UID ) 1

2 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 )? Password-based authentication: case#1 UID : S UID authentication request UID proof request proof = S UID user (UID) secret (S UID ) checks if indeed proof = password (= S UID ) Password-based authentication: case#2 authentication 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 ) 2

3 Password-based authentication pro: simple for the user cons: password storage (post-it!) password readable during transmission i password guessable (my son s name!) the 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 (Symmetric) challenge-response systems 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 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 3

4 Symmetric challenge-response systems authentication request UID user (UID) proof request + challenge UID : S UID proof secret (S UID ) checks if indeed proof = H(challenge,S UID ) computes proof = H(challenge, S UID ) (Asymmetric) challenge-response systems a random number R is encrypted with the user's public key and the users replies by sending R in clear thanks to its knowledge of the private key cert (Lioy, KpubLioy) user challenge = E (R, KpubLioy) 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 dthe sends Ri in clear and ask kitb back encrypted with user s private key... then the user has unwillingly signed the document!!! 4

5 One-Time Passwords (OTP) original idea: Bell Labs 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 ti computed by an ad-hoc application eventual integration into the communication sw (e.g. telnet client) or hw (e.g. modem) OTP problems generally uncomfortable uncomfortable when used to access multiple password-based 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 5

6 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 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 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 6

7 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 SecurID Key Fob: usable as a key fob SecurID modem: PCMCIA-II 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) SecurID: architecture ACE token OK? token OK? ACE client OK! KO! ACE client TELNET DBMS user, PIN, TC user, TC* TELNET client SecurID (normal) DBMS client SecurID (pinpad) 7

8 Example RSA SecureID SecurID: client ACE/client manages the dialogue with the ACE/ encrypted channel sd_ftp for secure FTP available for: Unix Win32 Netware Macintosh TACACS SecurID: ACE/: 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. ) products available for Solaris, AIX, HP-UX, NT, 2000, XP 8

9 CRYPTOCard challenge-response mechanism based on DES-CBC single product: RB-1 card 8 digits (hex, dec) LCD display user-replaceable battery (change every 3-4 years) to avoid inserting the challenge, can store the last one and automatically compute the next one for Unix and Windows (Radius, Tacacs+) CRYPTOcard: hardware 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 9

10 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 FAR / FRR Kerberos authentication system (not authorization) trusted key system initially developed as part of MIT project Athena 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 two versions in use: 4 & 5 10

11 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 s distributed throughout the network s 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 (cont.) threats: a user may gain access to a particular workstation and pretend to be another user operating from that workstation a user may alter the network address of a workstation so that the requests sent from the altered workstation appear to come from the impersonated workstation a user may eavesdrop on exchanges and use a replay attack to gain entrance to a or to disrupt operations unwanted result:=> unauthorized user would gain access to services/data she is not authorized to Kerberos (cont.) s must confirm the identities of clients undertaking this task in an open environment places a significant burden on solution: use an authentication (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 in the Kerberos domain, that is the set of systems that use Kerberos as authentication system (distributed physically or in some other secure manner) 11

12 Kerberos (simple authentication dialog) K S AS Authentication Server {TGT} s request client user ID, {TGT} s (application) Kerberos (simple authentication dialog) request: (user s ID, 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 => AS accepts the user as authentic and must convince the (application) creates {TGT} s : (user s ID, network address, s ID) encrypted with the shared secret s client cannot forge {TGT} s : 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, file, etc) solution: use a Ticket Granting Server (TGS) AS sends to client a ticket-granting ticket (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 TGT is used to authenticate user to TGS and get a servicegranting ticket (Ts) for a particular service 12

13 Kerberos ticket (TGT, Ts) ticket data structure to authenticate a client to a variable lifetime (V4: max 21 hours = 5 x 255) (V5: unlimited) encrypted with the DES key of the target bound to the IP address of the client bound to just one credential simple or mutual authentication 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) Kerberos versions MIT V4 (the original public one) MIT V5 (RFC-1510) not only DES extended ticket lifetime (begin-end) inter-realm 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 13

14 Kerberos: problems clock synchronization required: within a LAN it s useful anyway in WAN may originate problems Kryptoknight (alias IBM NetSP) doesn t require clock synchronization remote access needs cleartext password: encrypted channel or integration with OTP, symmetric or asymmetric challenge Kerberized dial-up modems 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 14