A company I know is in discussions to firm up its password security policy across all its web application products.
Right now they are sending username / password authentication in POST forms over HTTP, and thus, they are being sent plaintext.
The simplest solution to the problem is simply to require HTTPS for logon across all our applications, right?
Well, there's some internal discussion about instead doing some kind of roll-our-own client-side encryption of passwords (password + salt, etc.).
Is there an accepted HTTP-only solution?
Opinions are like... well, everyone has an opinion, so I'm looking for credible security literature that can support your recommendation. Don't just google and send me to a blog post... I've already done that and further.
I have found OWASP's recommendations: http://www.owasp.org/index.php/Top_10_2007-A7#Protection
As well as Microsoft's: http://msdn.microsoft.com/en-us/library/aa302420.aspx
EDIT: Giving your recommendation for using SSL isn't enough. I need some kind of supporting documentation. I KNOW that rolling our own client side encryption is bad. I need to be able to credibly sell that to co-workers and management.
Also, HTTP Digest has been mentioned. Seems nice, but Digest is ONLY for HTTP authentication, and not for data sent over POST.
+1 to Mehrdad's answer. Going ahead with home-grown cryptography is risky.
Speaking from experience here, after having seen vulnerabilities in home-grown client-side encryption solutions. Most of the vulnerabilities are due to the same reason - the data transfer was protected by encryption with a secret key, but the key itself was exchanged in an insecure manner.
TLS/SSL solves the problem of not just secure key exchange, but also of secure data transfer.
TLS/SSL protects your sensitive information by using assymmetric key cryptography to exchange the symmetric key used to encrypt information back and forth, once the TLS/SSL session has been established. The symmetric key is generated at runtime, and is a shared secret between the client and the server; it is this key that is used to encrypt all other traffic once the session is ready for transfer of data.
The server's public and private keys are used only to exchange this shared secret. The only known way to compromise the shared key is to compromise the server's private key (so that the secret key can then be decrypted). In reality, it requires negligence or malice on the part of the server administrator.
If you roll your own encryption solution, you must exchange the symmetric key, in a secure manner. The easiest way to do so is to use TLS/SSL; the harder way is to implement your own assymmetric key exchange cryptography solution.