Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
The OWASP Application Security FAQ recommends the use of JavaScript to produce a salted hash of the password client-side with JavaScript prior to sending it to the server.
By storing a staled hash of the password and then using this same hash as an authentication token, an application is more vulnerable to attack because this application is now storing authentication credentials in plain-text. An attacker can use SQL Injection to read this hash and then authenticate without having to crack the hash to obtain the plaintext password.
The OWASP wiki entry refereed in this question was misleading and was removed:
Here is how the salted MD5 technique works: the database stores a MD5 hash of the password. (MD5 hash is a cryptographic technique in which the actual value can never be recovered.) When a client requests for the login page, the server generates a random number, the salt, and sends it to the client along with the page. A JavaScript code on the client computes the MD5 hash of the password entered by the user. It then concatenates the salt to the hash and re-computes the MD5 hash. This result is then sent to the server. The server picks the hash of the password from its database, concatenates the salt and computes the MD5 hash. If the user entered the correct password these two hashes should match. The server compares the two and if they match, the user is authenticated.
MD5 is not appropriate for passwords. This is a broken primitive and a violation of CWE-916. Even if this was describing a secure challenge response, HTTPS is a more appropriate tool and is required to protect the session id.
hp) on the client with user-salt-a (sa), you also encrypt the hashed password (ehp) once it gets to the server with user-salt-b (sb). Then your user gets sa when they log into the client to re-generate hp and that is then re-validated on the server that ehp matches fn(sb, ehp). In this way the original password never leaves the client, reducing the probability of a cross-service attack from hash lookup databases. Check your AWS network traffic and see if they send original passwords :)