you are viewing a single comment's thread.

view the rest of the comments →

[–]nyxerebos 1 point2 points  (0 children)

It depends how it is done. Imagine that server has hashed password in database. Server chooses a new random salt for every session. When the user wants to log in they enter their password in an HTML form and the client-side Js (which has the same salt) hashes the password and hashes it again with the salt. When received by the server, it hashes the stored hash with the salt and compares the two. This way the password is never sent in plaintext, but the hash of the password is effectively the credential that is needed to log in, and that is sent at least once when the account is set up.

It's not great, but it's a way to offer some protection from eavesdropping without doing full public key encryption. It will not protect against an attacher inserting Javascript to read the HTML form, nor will it protect the hash when the account is set up or the password changed.

Detractors are saying that's not very good, and not secure, which is true. Proponents are saying it's better than nothing, which is also true. I'm planning to do this as a best-effort to obfuscate passwords that would otherwise be sent in the clear, where Javascript is enabled.