“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• E-mail 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