Authentication What you know? What you have? What you are?

Authentication CSCE Farkas/Eastman -- Fall Authentication Allows an entity (a user or a system) to prove its identity to another entity Typically, the entity whose identity is verified reveals knowledge of some secret S to the verifier Strong authentication: the entity reveals knowledge of S to the verifier without revealing S to the verifier

Authentication CSCE Farkas/Eastman -- Fall Authentication Information Must be securely maintained by the system.

Authentication CSCE Farkas/Eastman -- Fall Elements of Authentication Person/group/code/system Distinguishing characteristic Proprietor/system owner/administrator Authentication mechanism Access control mechanism

Authentication CSCE Farkas/Eastman -- Fall Authentication Requirements System must ensure Data exchange is established with addressed peer entity and not with an entity that masquerades or replays previous messages Data source is the one claimed

Authentication CSCE Farkas/Eastman -- Fall Authentication vs. Identification Identification – Who are you? Authentication – Why should we believe you? Authentication generally follows identification

Authentication CSCE Farkas/Eastman -- Fall User Authentication What the user knows Password, personal information What the user possesses Physical key, ticket, passport, token, smart card What the user is (biometrics) Fingerprints, voiceprint, signature dynamics

Authentication CSCE Farkas/Eastman -- Fall Passwords For each user, system stores (user name, F(password)), where F is some transformation (e.g., one-way hash) in a password file When user enters the password, system computes F(password); match provides proof of identity

Authentication CSCE Farkas/Eastman -- Fall F(password) Password  F(password): easy F(password)  password: hard Password is not stored in the system

Authentication CSCE Farkas/Eastman -- Fall Vulnerabilities of Passwords Easy to guess or snoop No control on sharing Visible if unencrypted in networks Susceptible for replay attacks if encrypted naively

Authentication CSCE Farkas/Eastman -- Fall Advantages of Passwords Easy to modify compromised password System well understood by most users Specialized hardware not needed

Authentication CSCE Farkas/Eastman -- Fall Weak Passwords Bell Labs study (Morris and Thompson, 1979), 3289 passwords were examined Summary: 2831 passwords (86% of the sample) were weak, i.e., either too easy to predict or too short

Authentication CSCE Farkas/Eastman -- Fall Study Details 15 single ASCII characters 72 two ASCII characters 464 three ASCII characters 477 four ASCII characters 706 five letters (all lower case or all upper case) 605 six letters, all lower case 492 weak passwords (name, dictionary words, etc.)

Authentication CSCE Farkas/Eastman -- Fall Password Attacks Guessing attack Dictionary attack Social engineering Spoofing attack Other attacks (covered later)

Authentication CSCE Farkas/Eastman -- Fall Guessing Attack Exploits human tendency to use easy to remember passwords Trial-and-error attack Easy to detect and block (failed logins) Need audit mechanism

Authentication CSCE Farkas/Eastman -- Fall Dictionary Attack Attack 1: Create dictionary of common words and names and their simple transformations Use these to guess password Attack 2: Usually F is public and so is the password file (encrypted) Compute F(word) for each word in dictionary Find match

Authentication CSCE Farkas/Eastman -- Fall Social Engineering Attacker asks for password by masquerading as somebody else (not necessarily an authenticated user) May be difficult to detect Protection against social engineering: strict security policy and user education

Authentication CSCE Farkas/Eastman -- Fall Login Spoofing Create a fake login screen Capture login and password when user attempts to log in Present a fake failed login screen User may not even notice there is a problem

Authentication CSCE Farkas/Eastman -- Fall Password Defenses Password salt Password management policies Lamport’s scheme One time passwords Time synchronization Challenge response

Authentication CSCE Farkas/Eastman -- Fall Password Salt Used to make dictionary attack more difficult Salt is a 12 bit number between 0 and 4095 Derived from system clock and the process ID Compute F(password+salt); both salt and F(password+salt) are stored in the password table User: gives password, system finds salt and computes F(password+salt) and checks for match Note: with salt, the same password is computed in 4096 ways

Authentication CSCE Farkas/Eastman -- Fall Password Management Policies Educate users to make better choices Define rules for good password selection and ask users to follow them Ask or force users to change their password periodically Actively attempt to break user’s passwords and force users to change broken ones Screen password choices

Authentication CSCE Farkas/Eastman -- Fall Lamport’s scheme Doesn’t require any special hardware System computes F(x),F 2 (x),…, F 100 (x) (this allows 100 logins before password change) System stores user’s name and F 100 (x) User supplies F 99 (x) the first time If the login is correct, system replaces F 100 (x) with F 99 (x) Next login: user supplies F 98 (x) … and so on User calculates F n (x) using a hand-held calculator, a workstation, or other devices

Authentication CSCE Farkas/Eastman -- Fall One-time Password Use the password exactly once! Often done for initial assigned passwords User must change password before doing anything else

Authentication CSCE Farkas/Eastman -- Fall Time Synchronized There is a hand-held authenticator It contains an internal clock, a secret key, and a display Display outputs a function of the current time and the key It changes about once per minute User supplies the user id and the display value Host uses the secret key, the function and its clock to calculate the expected output Login is valid if the values match

Authentication CSCE Farkas/Eastman -- Fall Challenge/Response Work station Host Network  Non-repeating challenges from the host  The device requires a keypad User ID Challenge Response

Authentication CSCE Farkas/Eastman -- Fall Challenge/Response Problems Key database is extremely sensitive This can be avoided if public key algorithms are used

Authentication CSCE Farkas/Eastman -- Fall Devices with Personal Identification Number (PIN) Devices are subject to theft Some devices require PIN (something the user knows) PIN is used by the device to authenticate the user

Authentication CSCE Farkas/Eastman -- Fall Smart Cards Portable devices with a CPU, I/O ports, and some nonvolatile memory Can carry out computation required by public key algorithms and transmit directly to the host Some use biometrics data about the user instead of the PIN

Authentication CSCE Farkas/Eastman -- Fall Biometrics Fingerprint Retina scan Voice pattern Signature Typing style Hand geometry

Authentication CSCE Farkas/Eastman -- Fall Problems with Biometrics Expensive Retina scan (min. cost) about $ 2,200 Voice (min. cost) about $ 1,500 Signature (min. cost) about $ 1,000 False readings Retina scan 1/10,000,000+ Signature 1/50 Fingerprint 1/500 Can’t be modified when compromised

Authentication CSCE Farkas/Eastman -- Fall Errors in Biometrics False rejection rate (FRR) Authorized subject is rejected False acceptance rate (FAR) Unauthorized subject is accepted Crossover error rate (CER) FRR = FAR

Authentication CSCE Farkas/Eastman -- Fall Two-factor Authentication Require two forms of authentication Password + smart card PIN + hand geometry

Authentication CSCE Farkas/Eastman -- Fall Wellness Center Identification – SSN Authorization – hand geometry High change of random hands matching Low chance of your friend’s hand matching yours

Authentication CSCE Farkas/Eastman -- Fall Single Sign-On (SSO) Provide identification and authorization once for a set of related systems VIP limited SSO Kerberos (ker-ber-OUS) Symmetric key cryptosystem Trusted third party (Key Distribution Center (KDC) – a trusted third party

Authentication CSCE Farkas/Eastman -- Fall Responsibility for Data Data owner (data administrator) Sets policies Data custodian (database administrator) Implements policies Data user (database user) Follows policies

Authentication CSCE Farkas/Eastman -- Fall Chapter Topic Review Access control Identification and authentication Possible threats Miscellaneous examples