W3C

Passwords in the Clear

TAG Finding October 08 2008

Latest version:
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
This version:
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20081008.html
Previous version(s):
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080912.html
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080602.html
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080501.html
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080421.html
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080211.html
Previous version(s):
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080124.html
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20071108.html
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061212.html
Editor:
David Orchard, Invited Expert orchard@pacificspirit.com (and before at BEA Systems)
Previous Editor:
Ed Rice, Hewlett Packard Ed.Rice@hp.com (until Dec 2006)

Abstract

The purpose of this finding is to provide guidance for securely transmitting passwords on the World Wide Web. Clear text passwords are a serious security risk. Digest authentication has significant advantages over clear text passwords, though other security issues arise. The use of an encrypted channel or key exchange is always more secure.

Status of this Document

This document has been produced by the W3C Technical Architecture Group (TAG). This finding addresses TAG issue passwordsInTheClear-52. The TAG approved this finding at its October 16th 2008 weekly telephone conference.

Additional TAG findings, both accepted and in draft state, may also be available.

Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org (archive).

Table of Contents

1 Introduction
2 Passwords in the clear
    1) Secure transfers
       1) Digest Authentication
       2) SSL/TLS
       3) WS-Security
   2) SOAP Based transmissions
3 Passwords displayed in Browser
4 Password Alternatives
A References
 


1 Introduction

Security on the World Wide Web is an important issue which needs to be addressed, or mistrust of the Web will limit its growth potential. This finding describes the use of passwords on the World Wide Web and the need to keep them secure during display, temporary storage in cookies, and in transmission over the Web. Note that there are technologies other than passwords for enabling the transmission of secure informaton.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [ IETF RFC 2119]

2 Passwords in the clear

This section addresses the issue of transmitting passwords in clear text over the World Wide Web. When a password is transmitted in clear text, it is vulnerable in many ways:

  1. The password is available on the wire. As the password is transmitted over the wire, tools such as packet sniffers or network analyzers can easily monitor the traffic and intercept passwords as they're sent between computers.
  2. The password is available in browsing history. Most web browsers provide 'back' navigation to previous pages, with content locally cached for performance as well as ease of use for the user. These pages are stored in memory and are relatively easy to examine.
  3. The password is readable on web proxies. Many larger corporations, as well as internet service providers, offer web proxies to allow faster downloads as well as some level of anonymity for web users.

The HTTP specification specifically states that HTTP is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL).

It is estimated that between 1 and 2 percent of e-commerce transactions are related to fraud. As customers are becoming more 'net savvy', they are starting to examine web page types and are attempting to only use secure systems. Therefore, any organization that wishes to safeguard its customers' data should start with secure transfers of user login and password information.

Good Practice

Clear text passwords are a serious security risk. Transmit passwords in the clear only in interactions that do not need to be secure and do not lead to vulnerabilities in other interactions.

There are no scenarios where it is possible to transmit passwords in the clear without risk. Every scenario that involves possibly transmitting passwords in the clear can be redesigned for the desired functionality without a clear text password transmission. One vulnerability that may be created with clear-text passwords is if the same password in the clear text interaction is re-used in other interactions. Users and administrators should take appropriate steps, such as warnings, to mitigate such a vulnerability if clear text passwords are used.

Automatic Protection by User agent

It is tempting to build user agents that refuse to send sensitive data in the clear, or to warn users. There are two problems. Firstly, the user agent cannot determine which data or information is sensitive. Sensitive information is not always input using password masking, often for good reason. Secondly, when the user agent is running arbitrary code, such as when javascript is enabled, a program or script can be used to process a clear text form field (possibly a password) for transfer in many ways and scripts are difficult or impossible for the browser to analyze.

2.1 Secure transfers

While it's not the purpose of this paper to do an exhaustive description of secure transfer methods on the Web, there are a few common methods used today which are easy to implement;

2.1.1 Digest Access Authentication [Digest]

Digest Authentication acts as an extension to HTTP 1.0 and provides an authentication method that does not transmit the password over the network. Instead the password is treated as a secret input to a digest algorithm. The resulting digest is transmitted and verified by the server.

Good Practice

Digest authentication has significant advantages over clear text passwords, though other security issues arise.

The digest method is often not practicable and has known security weaknesses. The Digest method requires that both parties have access to the same initial secret value ( described in Security Reference 2.3.3 Passwords for Network Authentication). For security of the passwords, many systems store passwords as a salted hash, and the result is that it is not possible to use such pre-existing passwords for computing the digest ( described in Security Reference 2.3.2 Passwords for Local Access). For example, operating systems that store salted and hashed passwords cannot reuse those passwords for Digest Authentication. Passwords that are stored as a salted hash must also be salted and hashed by the user agent or client using the same salting and hashing algorithm, and the protocol for specifying the exact data and algorithm goes beyond the Digest Authentication specification. The Digest method is subject to dictionary attacks because a single session can be recorded and attacked offline. The Digest method is particularly vulnerable in circumstances where passwords are known to be of insufficient length and complexity to thwart such attacks. Short passwords or those using common words should not be used with digest authentication. Indeed, the sophistication and power of dictionary-based attacks continues to increase such that longer and more complex passwords are increasingly vulnerable to attack. Great care must therefore be taken using digest authentication, and it should be noted that few systems on the Web today require sufficiently strong passwords. The Digest method is also subject to man in the middle attacks because an intermediary can degrade the quality of service to basic authentication.

Given these weaknesses in Digest Authentication and password selection, users may erroneously believe the transmitted passwords are secure. Digest should only be used when the costs of more secure systems such as SSL/TLS do not justify the benefits and when strong passwords are encouraged or guaranteed.

2.1.2 Secure Socket Layer (SSL/TLS)

SSL/TLS is a protocol developed for transmitting private channels via the Internet. SSL/TLS works by using a private key to encrypt data that is transferred over the SSL/TLS connection. Most browsers support SSL/TLS and most sites which require sensitive information such as credit card information use SSL/TLS today.

Good Practice

The use of an encrypted channel or key exchange is always more secure than clear text passwords or Digest Authentication.

It is important to correctly use SSL/TLS. Any page that solicits sensitive information such as passwords must be transmitted using SSL/TLS to prevent an attacker from submitting an imitation page that does not use SSL/TLS.

2.1.3 WS-Security

WS-Security is typically used with SOAP based transmissions, but has been applied to the Atom Publishing protocol.

2.2 SOAP Based transmissions

SOAP messages are often sent using HTTP and any SOAP message is subject to similar password security concerns. While SSL/TLS can be used to secure SOAP-based messages point to point, the issue can be more complex if SOAP intermediaries are used. If confidential information is to be sent as part of the SOAP package, publishers can use use SSL/TLS, XML Encryption, and WS-Security for sensitive data elements. Further information on security for SOAP messages can be found in WS-I Basic Security Profile [WSI] or on the OASIS Web Services Security TC home page [WSS].

3 Passwords displayed in Browser

HTML allows authors to create input forms. If a form field is a password, password masking SHOULD take place to protect the user from onlookers seeing what is being entered and stop anyone from later using the 'back' button to discover passwords.

Example:
<form name="form1" action="https://www.mydomain.com/myform.cgi" method="POST">
    Enter Password : <input type="password" size="25"/>
</form>

Good Practice

User agents SHOULD use password masking when passwords are displayed in an HTML form.

This Good Practice does not contain a MUST because there are a few scenarios where password masking is not required. One example is that the user may request that the password be displayed in the clear in order to check the password as it is being entered. Another example is the previous example of a password intended merely to stop web crawling and which consequently is not particularly sensitive. Such non-sensitive passwords may be displayed without masking in addition to being transmitted in clear text.

A browser should also ensure that password form fields are not stored in the browser cache.

4. Password Alternatives

A solution to sending username/password combinations to many different web sites is to use single sign-on or delegated authorization technology, such as SAML, OpenId and OAuth. Another solution is to use client certificate-based authentication. Finally, two-factor security is growing in popularity. An example is security password token generators where a number or PIN that is known to the user is combined with a regularly random generated number by a hardware token as the password.

A References

[AtomPub]:Atom Publishing Protocol, RFC 5023, Proposed Standard, IETF. Available online as http://tools.ietf.org/html/rfc5023

[IETF RFC 2119]: http://www.ietf.org/rfc/rfc2119.txt

[Bulletproof Wireless Security]: Bulletproof Wireless Security. Available online as http://books.google.com/books?id=2c_VEOThyMUC&printsec=frontcover&source=gbs_summary_r&cad=0#PPA39,M1

[W3C Security]: W3C Security Home

[Digest]: HTTP Authentication: Basic and Digest Access Authentication, RFC 2617, Draft Standard, IETF. Available online as http://www.ietf.org/rfc/rfc2617.txt.

[WSI]: WS-I Basic Security Profile, WS-I. Available online as http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html.

[WSS]: OASIS Web Services Security (WSS) TC.

[OpenID]: http://openid.net/

[OAuth]: http://oauth.net/

[SAML]: OASIS SAML TC