A problem with many challenge-response login systems is that the server has to store a password equivalent. For example, if the server stores SHA1(salt + password), and an attacker captures that hash, then they would be able to directly use the hash to login, without having to crack the password.

I believe there are some variations of challenge-response login that avoid this weakness. In particular, I have heard that newer versions of MySQL have fixed it. I do not have any references or further information on this, but I would like to know how this can be done. I can imagine some approaches myself, but I would prefer to use a standard, peer-reviewed protocol.

I am aware that SRP solves this problem. However, SRP is more a public key protocol rather than challenge-response. I am particularly interested in protocols that only use symmetric ciphers, hashes, and maybe some XORing, etc.

  • How do they directly use the hash to login? If they provide the hash, the server will try salting and hashing the hash, get a different value than what it has stored and fail the authentication. May 16, 2014 at 13:37
  • @AJHenderson - this specifically about challenge-response logins. A typical setup is that the server stores hash(salt+password) and to login a user must send hash(challenge+hash(salt+password)). In that case, if an attacker already knows hash(salt+password) they can complete the login process and impersonate the user.
    – paj28
    May 16, 2014 at 13:47
  • why does the server bother storing a hash rather than the actual secret then? The hash serves no purpose other than to increase the time it takes to authenticate. A challenge response should be hash(challenge + secret + salt). I guess that your question is if there is a way to do it without having to store the secret on the server though right? (since the normal algorithm still requires storing the secret used by the user.) May 16, 2014 at 13:57
  • @AJHenderson - fair question, but somewhat moot as the link from timoh has a better solution.
    – paj28
    May 16, 2014 at 14:02
  • yeah, I was just trying to understand the question because the use of a hash to generate the secret from the password serves no purpose. It doesn't answer your question (which is why I commented), it was just something that didn't make sense to me. May 16, 2014 at 14:02

1 Answer 1


Both the algorithms described here suits your description (doesn't require to store plaintext-equivalents on the server, achieves stretching and are simpler than public-key setups): http://openwall.info/wiki/people/solar/algorithms/challenge-response-authentication

You must log in to answer this question.

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