The purpose of this finding is to clarify the security concerns around using passwords on the World Wide Web. Specifically, the objective is to point out that passwords SHOULD NOT be transmitted in the clear except in a few very specific cases.
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.
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. Specifically this paper talks about the use of passwords on the WWW and the needs to keep them secure during display, temporary storage in cookies as well as transmission of that data over the Web.
The TAG feels there are sufficient technologies available to take a clear stance on password security as it relates to the World Wide Web.
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 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 systems 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 use only secure systems. Therefore it's imperative that any organization that wishes to safeguard its customers' data start with secure transfers of user login and password information.
A server or resource SHOULD NOT solicit any passwords in clear text.
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 would be a test page that has no sensitive information on it where the only reason for the prompting of the password is to stop it from being indexed by a major search engine. Placing a password on the page is a simple way to stop the crawling of the pages without really having to 'secure' the content. Because users often cannot tell when a password is being send in the clear or not, we could use another 'Good Practice' to make sure that users are aware of the resulting vulnerability, and go on to use the same password again for a application intended to be secure.
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 acts as an extension to HTTP 1.0 and offers a way for authentication to happen 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. Unfortunately the Digest method requires that both parties have access to the same initial secret value. Because most passwords are stored as a salted hash, it is not possible in practice for both parties 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's transferred over the SSL/TLS connection. Most browsers support SSL/TLS and most sites which require credit card information use SSL/TLS today. Originally developed by Netscape there are now many different authorities providing private keys.
SOAP communicates over HTTP and is subject to similar password security concerns. While SSL/TSL can be used to secure SOAP-based messages point to point, the issue can be more complex if SOAP intermediaries are used. The TAG's position on SOAP remains consistent: that passwords and sensitive information MUST 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].
HTML allows authors to create input forms for multiple purposes. It is the TAG's opinion that 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.
<form name="form1" action="http://www.mydomain.com/myform.cgi" method="POST"> Enter Password : <input type="password" size="25"/> </form>
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. For example, the user may request that the password is displayed in the clear or the password is intended only to prevent search engine access.
[WSI]: Security Challenges, Threats and Countermeasures Version 1.0, WS-I. Available online as http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf.