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 for 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 Team at the W3C.
Security on the world wide web is an important issue which needs to be addressed or the mistrust of the web will limit its growth potential. Specifically this paper talks about the user 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 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 are transmitted in clear text, it is vulnerable in many ways;
a) 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.
b) The password is available in browsing history. Most web browsers allow you to navigate 'back' to previous pages, the content is cached for performance as well as ease of use for the user. These pages are stored in memory and are relatively easy to examine.
c) The password is readable on the web proxies. Many larger corporations, as well as internet service providers, offer web proxies to allow users faster downloads as well as some level of anonymity to web browsers.
The HTTP spec 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).
The Yankee Group2 estimates that between 1 and 2 percent of ecommerce transactions are related to fraud. As customers are becoming more 'net savvy' they are starting to examine the web page types and are attempting use only secure systems. Therefore its imperative that any organization who wishes to safeguard its customers data start with secure transfers of user login and password information.
A server SHOULD NOT solicit any passwords in clear text.
A client or browser SHOULD NOT transmit passwords in clear text.
A user agent MUST notify the user prior to sending the password in clear text.
While its 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 acts as an extension to HTTP 1.0 and offers a way for authentication to happen between parties using a 'shared secret' (a password). This verification method can be done without transmission of the password in clear text to address the HTTP 1.0 Basic method of authentication. The Digest method assumes that the username and password are prearranged. The requirement to prearrange usernames and passwords may complicate or prevent the user of Digest Authentication certain applications.
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 for private key.
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 to 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 user SSL/TLS or XML Encryption for sensitive data elements. Further information on security SOAP messages can be found in the document; WS-I "Security Challenges, Threats and Countermeasures Version 1.0" 3 or on the OASIS Web Services Security TC home page4.
HTML allows authors to create input forms for multiple purposes. It is the TAG's opinion that if the form field is a password, password masking must take place to protect the user from on-lookers seeing what is being entered and stop some 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">
User agents MUST use password masking when passwords are displayed in the html form
WS-I "Security Challenges, Threats and Countermeasures Version 1.0". Available online as http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf