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.

  1. Is this something truly advocated?
  2. Should I go this route, how should the page behave should JavaScript be disabled? I imagine that signing in will be disallowed?
  • 1
    Mind copying whatever you saw there and pasting it here? that's an zeful long page to hunt for one or two lines...
    – atk
    Nov 11, 2013 at 3:02
  • User Michael Brooks has removed the offending statement already earlier, but here is the diff. Actual text quoted in this response.
    – Paul
    Nov 11, 2013 at 5:19

1 Answer 1


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.

  • Thank you, that OWASP recommendation did sound very strange to me so I asked here. Glad to see my suspicions were verified.
    – Paul
    Nov 11, 2013 at 5:22
  • I think you missed the point of the OWASP recommendation. You don't only hash the password (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 :)
    – f1lt3r
    Sep 6, 2018 at 13:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .