Review of Existing Web Authentication Mechanisms

Fact Finding Mission

Web authentication usually establishes that a client knows a shared-secret (password). But why?

Secure access: confidentiality, message integrity, etc.
Resource conservation: limit access to data with poor caching characteristics
Affinity programs: observe users interact with server, adjust accordingly. (just like the grocery store)

Many deployments have requirements from each of these areas. They sometimes conflict.

You can solve any problem...

...for better or worse.

Almost all HTTP authentication is accomplished through HTML forms, with session keys stored in cookies.
Netscape specification and RFC 2109 are well-supported. Later work is not.
HTML4 is well-supported. Later specs, including all XHTML versions, are not.

Why?

Presentation control: opportunity for affinity, opportunity for spoofing.
Internationalization: if you implement carefully, you can get UTF-8 in and out.
Disable Autocomplete: sites can indicate password should never pre-populate (MS extension).
Logout buttons: Easy for client to end the session.
Scalability

HTTP 1.1 provides a simple authentication framework: Basic and Digest are in 2617.
Rarely used.
No presentation control, logout capabilities, or interoperable internationalization.

Usernames and passwords in the clear.
Easy to implement.
Not at all secure, unless used over a secure transport.
Poor scalability properties, because credentials must be revalidated with every request.
Secure transports negate many of HTTP's caching mechanisms.
Compatible with any authentication database!
Users vulnerable to mismanaged or malicious servers, even over a secure channel.

Client transmits the results of hashing user credentials with properties of the request and values from the server challenge.

Some properties that are preferable to Basic and Cookies.

Credentials are not trivially reusable by parties that observe them, at least in comparison to Basic.
Session data transmitted in each request, allowing servers to validate credentials only when absolutely necessary.
Authentication session keys are distinct from other protocol traffic.

Spec is complicated: only the simplest modes enjoy any degree of interoperability.
Message integrity design is flawed: requires full message to be processed.
Requires that authentication databases be designed to accomodate it.
Capabilities included to prevent replay attacks expose the server to DOS attacks.
Offline dictionary attacks
2617 Security Considerations has more info

Microsoft NTLM: connection bound

Amazon AWS: digest variant combined with tickets...

All have desirable security properties, but users can't tell when they are using them.

Sites with requirements for resource conservation and affinity programs deploy weak schemes
Users game password complexity checks: Blink182!, Class-Of-2007!
Usernames predictable
Users reuse the same credentials
Only as strong as the weakest site your user visits