Some Problems and Possible Solutions in Web Authentication

Problems

• Passwords in the clear
  • HTTP Basic authentication was designed when telnet passwords-in-the-clear were the norm
  • it protects against casual eyeballing by base64-encoding credentials, 
  • this provides no obstacle to an attacker that can write even trivial amounts of software
• TLS/SSL is compute-intensive and hence cost-prohibitive for many applications
  • encrypting all the content is overkill if the problem is just user authentication
• HTTP authentication headers are not expressive enough to effectively convey a request for credentials
  • they provides only a cryptic "realm" string to convey the identity of the relying party; this is an unacceptable way to communicate a trusted identity or brand
• HTML forms with <input type="password"> obscure the password from view and suggest to the user that their password is being kept confidential when (unless TLS/SSL is also in use) it is not.
• Each service provider manages credentials separately
  • Users are burdened with managing separate credentials for each service
  • • Many choose not to
  • New services are difficult to launch without endorsement of an established brand, concentrating power and stifling innovation.

See Problems with HTTP Authentication Interop by Joe Gregorio, January 10 2006, for an entertaining and detailed account of these problems.

State of the Art

• HTML forms for presenting credential requests
• cookies for protocol credentials
• TLS/SSL for confidentiality (optional; additional cost)
• Users manage a few accounts, mostly with popular branded portals

Medium Term Solutions

i.e. in future browser releases

• User Agent Authentication Forms, a submission to W3C in 1999
  • combines HTTP digest authentication with a forms interface to provide confidential shared-secret authentication without the cost of TLS/SSL.
  • also provides for logout controls

Near Term Solutions

i.e. technology that can be deployed in advance of widespread adoption of new standards

• OpenID
• • allows services to be decoupled from credential management
  • allows users to maintain an identity independent of credential management service
  • provides single-sign-on
    • introduced as a counter-measure to blog comment spam
    • designed to complement trust/reputation systems
    • suitability for high-security situations (e.g. financial transactions) is less clear
  • requires only widely deployed browser features (HTTP, forms, cookies, redirection)
  • implementations are available for/in an increasing number of popular web application tools and platforms: perl, PHP, python, Ruby on Rails, drupal, MoinMoin, ...

From a Liberty case study at XML 2005, it seems that ID-FF has a similar design to OpenID, but I am much less familiar with it.