Passwords in the Clear
[Mez’s version of Editor's
Draft] TAG Finding passwordsInTheClear-52,v 1.02 2006/12/12 21:52:21
Abstract
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.
1 Introduction
Security on the World Wide Web is an important issue which needs to be
addressed or visible or publicized attacks on existing
vulnerabilities will create mistrust of the Web which
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.
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 allow you to navigate 'back' 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 users faster downloads as well as some level of anonymity for web users.
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).
It is estimated that between 1 and 2 percent of e-commerce transactions are
related to fraud. As customers are becoming more 'net savvy' hearing
more about web based attacks they are starting to examine web page types
and are attempting use only secure systems or to use
the systems they have securely. Therefore it's imperative that any
organization that wishes to safeguard its customers',
employees’ and users’ data 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.
Browsers can only follow good practice if they know
they are handling a password. Sites that do not use established protocols and
data conventions to signal the use of passwords to clients and browsers will
not benefit from this good practice. 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 need 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. Some sites attempt to reuse the notion of
passwords for other purposes, such as blocking indexing by search engines. Users
tend to choose the same password, or use the same algorithm for password
choice, and by and large have no reason to attempt to understand which
passwords are for security and which are for something else. It is a mis-use of
user generated passwords to use them for something else and to expose them on
the web. Only site generated and assigned passwords may be safely exposed, and
only if the user is clearly informed that password will not be protected by the
site that generated it.
Good Practice
A user agent MUST notify the user prior to
sending a password in clear text.
User agents may choose to not send a password in clear text instead
of notifying the user and sending it.
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 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 or contexts.
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. Self signed certificates may also be used to provide network confidentiality.
2.2 SOAP Based transmissions
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].
3 Passwords displayed in Browser
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 (or some other form of protection from physical proximity
capture) MUST take place to protect the user from onlookers seeing what
is being entered or later displayedand 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 MUST protect
password display when they knowingly display a password that will also be
protected in transituse password masking when passwords are displayed in an
HTML form.
If a password will not be protected in transit, protecting it in
display may confuse a user about its sensitivity. [comment – I’d
probably remove this entire recommendation myself, because the other two are so
much more important, and this one is just slowing them down.]
A References
[Digest]: HTTP Authentication: Basic and Digest Access Authentication, RFC 2617, Draft Standard, IETF. Available online as http://www.ietf.org/rfc/rfc2617.txt.
[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.