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:
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.
A server MUST NOT solicit any passwords in clear text.
There are no scenarios where it is possible to transmit passwords in the clear without risk. Every scenario that involves possibly transmitting passwords in the clear can be redesigned for the desired functionality without a cleartext password transmission.
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 which data or information is sensitive. Sensitive information is not always input using password masking, often for good reason. Secondly, when the user agent is running arbitrary code, such as when javascript is enabled, a program or script can be used to process a clear text form field (possibly a password) for transfer 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;
2.1.1 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.
However, the digest method is often not practicable and has known security weaknesses. The Digest method requires that both parties have access to the same initial secret value. Many For security of the passwords, many systems store passwords as a salted hash, and the result is that it is not possible to use such pre-existing passwords for computing the digest. For example, operating systems that store salted and hashed passwords cannot reuse those passwords for Digest Authentication. Passwords that are stored as a salted hash must also be salted and hashed by the user agent or client using the same salting and hashing algorithm, and the protocol for specifying the exact data and algorithm goes beyond the Digest Authentication specification. The Digest method is subject to dictionary attacks because a single session can be recorded and attacked offline. The Digest method is particularly vulnerable in circumstances where passwords are known to be of insufficient length and complexity to thwart such attacks. Short passwords or those using common words should not be used with digest authentication. Indeed, the sophistication and power of dictionary-based attacks continues to increase such that longer and more complex passwords are increasingly vulnerable to attack. Great care must therefore be taken using digest authentication, and it should be noted that few systems on the Web today require sufficiently strong passwords. The Digest method is also subject to man in the middle attacks because an intermediary can degrade the quality of service to basic authentication.
Given these weaknesses in Digest and password selection, users may erroneously believe the transmitted passwords are secure. Digest should only be used when the costs of more secure systems such as SSL/TLS do not justify the benefits and when strong passwords are encouraged or guaranteed.
2.1.2 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 sensitive information such as credit card information use SSL/TLS today.
It is important to correctly implement SSL/TLS. Any page soliciting sensitive information such as passwords must be transmitted using SSL/TLS to prevent an attacker from submitting an imitation page that does not use SSL/TLS.
2.1.3 WS-Security
WS-Security is typically used with SOAP based transmissions, but has been applied to the AtomPub protocol.
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 MUST 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].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 MUST 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 WS-I Basic Security Profile[WSI] or on the OASIS Web Services Security TC home page [WSS].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 MUST 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.0WS-I Basic Security Profile[WSI] or on the OASIS Web Services Security TC home page [WSS].