Status of this Document
This document has been produced by the W3C Technical Architecture Group (TAG).
This finding addresses TAG issue passwordsInTheClear-52.
This finding is an editorial
draft, not yet accepted by the TAG. This finding therefore does not have
any official standing and does not represent the consensus of the Technical
Architecture Group at the W3C.
Additional TAG findings,
both accepted and in draft state, may also be available. The TAG expects to
incorporate this finding according to the process of the W3C Recommendation
Track.
Please send comments on this finding to the publicly archived TAG mailing
list www-tag@w3.org (archive).
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.
There are sufficient technologies available to describe a clear position on
password security as it relates to the World-Wide Web.
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:
- 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.
- 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.
- 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
A server SHOULD NOT solicit any passwords in clear text.
Good Practice
A client or browser SHOULD NOT transmit passwords in clear text.
There are some cases where it
is acceptable to transmit passwords in the clear. One example is placing a password on a page is a
simple way to stop web crawlers without really having to 'secure'
the content. Administrators using a clear text password need to be aware that passwords used for this type of purpose SHOULD NOT re-use the same password in contexts that are more sensitive.
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 what is sensitive. It is not always input using password masking, often for good reason. Secondly, when javascript is enabled, the script can use the password in the clear in many ways, which are too difficult 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;
Digest
Access Authentication[Digest]:
Digest Authentication acts as an extension to HTTP 1.0 and provides a way for authentication between parties without transmitting 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. The Digest method requires that both parties have access to the same initial secret value. Many systems store passwords as a salted hash and it is not possible in practice for two parties using such systems to compute the same initial secret value.
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 credit card information use SSL/TLS today.
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. The previous Good Practice advice of "A client or browser SHOULD NOT transmit passwords in clear text" applies to SOAP messages and so passwords and sensitive information SHOULD be transmitted in a secure manner and not as clear text. If confidential information
is to be sent as part of the SOAP package, publishers SHOULD either use SSL/TLS
or XML Encryption for sensitive data elements. Further information on
security for SOAP messages can be found in Security Challenges, Threats and Countermeasures Version 1.0
[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="http://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 a password intended merely to stop web crawling and which consequently is not particularly sensitive.