Passwords in the Clear

There are some cases where it is acceptable to transmit passwords in the clear; one 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 placing a password on the a page is a simple way to stop the crawling of the pages web crawlers without really having to 'secure' the content. Because users often cannot tell when Administrators using a password is being send in the clear or not, we could use another 'Good Practice' text password need to make sure that users are be aware that passwords used for this type of the resulting vulnerability, and go on to use purpose SHOULD NOT re-use the same password again for a application intended to be secure. in contexts that are more sensitive.

Automatic Protection by User agent

However, many forms use onSubmit actions It is tempting to start javascript programs. These programs secure build user agents that refuse to send sensitive data in the password and then transmit clear, or to warn users. There are two problems. Firstly, the password and other information. A User Agent user agent cannot examine the determine what is sensitive. It is not always input using password masking, often for good reason. Secondly, when javascript to ensure that is enabled, the script can use the password is not transmitted in the clear text. Therefore this finding can provide no Good Practice advice in many ways, which are too difficult for the browser to User Agent authors. 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 offers provides 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 The Digest method requires that both parties have access to the same initial secret value. Because most Many systems store passwords are stored as a salted hash, hash and it is not possible in practice for both 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's 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. Originally developed by Netscape there are now many different authorities providing private keys.

2.2 SOAP Based transmissions

SOAP communicates over messages are often sent using HTTP and any SOAP message is subject to similar password security concerns. While SSL/TSL 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 TAG's position on previous Good Practice advice of "A client or browser SHOULD NOT transmit passwords in clear text" applies to SOAP remains consistent: that messages and so passwords and sensitive information MUST 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] .