“Stronger” Web Authentication: A Security Review Cory Scott

Problem Area Username and password are insufficient authenticators for high-value assets accessible via an untrusted network. Pressures: –Regulatory: FFIEC guidance / mandate –Consumer confidence –Financial loss: Phishing and fraudulent activity –Technical: Defense-in-depth for web applications

Authentication As Ceremony: Prior Work Introduced by Walker / Ellison –Model for protocols involving users as opposed to machines Authentication Mechanism, as defined by Kaliski, contains the following: –Selected authentication factors –Particular evidence about those factors; and a –Specific protocol for conveying the evidence

Authentication As Ceremony: Impact We can adopt compound authentication mechanisms that combine different factors and assign a level of risk to each factor. Example factors: –User credentials –IP Address –ISP / Geo-location –Challenge questions –Access device –Prior suspicious activity on any of the factors –Certificates –OTP tokens / scratch cards –Voice confirm / SMS messages –Nature or Business Impact of request As a result, we can have “risk-based authentication”.

Two-factor Too Much Consumer acceptance of traditional commercial two-factor solutions in the US untested and expensive. Industry Solutions: –Mutual authentication (watermarking / HA SSL certs) –Introduction of “soft” factors: Challenge questions Device identification Geolocation / IP Risk Profiling –Application of risk-based authentication decisions based on the above factors. (Note: Value, in terms of cost or risk reduction, has not been proven yet.)

Factors in Risk-Based Authentication Device Identification –Signed Key of (Browser + OS + Language + Time Zone) + Specific User Account –Can be mapped to particular IP, ISP, Country –Stored as HTTP Cookie and/or Flash Shared Object Geolocation / IP Risk Profiling –Behavioral analysis of user login activity –Blacklist or flag certain countries, ISPs –Subscribe to a “fraud network” Transaction-level analysis –Anomalous transaction activity increases risk profile In all of these cases, when a risk threshold has been breached, the application can force “stronger” authentication.

Second-Level Authentication Decisions Challenge questions or other Knowledge- Based schemes SMS messages as One Time Passwords Voice or Registered Telephone verification verification Access from previously registered device Fall-back to 2FA: Smart-cards, Physical OTP tokens, biometrics, etc.

Credential Disclosure: Threat Models Shoulder-Surf or The “Post-It” Debacle Keyloggers, Malicious Browser Helper Objects, and Rootkits –Differing Impact: Interactive vs. Harvesting Mode –Can the attacker generate traffic from the victim host? Man-in-the-Middle Phishing Sites (trust subversion / trickery) Cross-Site Scripting and Request Forgery and other client-side web vulnerabilities Acquaintance fraud (weakening the credential)

Attack Considerations Tomfoolery with enrollment / site-in-transition –Phishing vectors –Increased site complexity Challenge question fuzzy logic Can the phisher ask the challenge questions? Is the device identifier subject to attack?

Design Considerations How tight is the restriction by IP? The conditioning problem: How often do you challenge? Do you want to be married to images and watermarks? Hard to take away. Support issues –Customers struggle or want to expand images –Account lockout / reset gets more complicated