I'm currently setting up a basic username & hash based login process for a web application. The process consist of the following steps:

  1. User submits their username.
  2. Server responds with salt.
  3. User hashes the password and sends it and the username to the server.
  4. Server authenticates the user.

Obviously this is somewhat simplified and multiple steps during the actual hashing process is glossed over.

What I see here is a potential of enumerating existing usernames. If an attacker submits a non existing username - no salt will be provided, hinting the attacker whether or not the username is in use.


When a non existing username is provided, if I were to provide a random salt, does it prevent the attacker from enumerating the existing users?

Would such a precosion be so minor it might as well be skipped?


  • An attacker could see that the server is just spewing out random values.

1 Answer 1


The main problem with the proposed system is that an attacker probably wouldn't bother with the obtaining salt step. They don't need to - the salted password is a password equivalent, so it's easier to jump in at step 3, and send pregenerated hashes to your server.

In terms of username enumeration, yes, it would be possible to determine whether a user exists given the response of salt or not. Depending on your system, it might also be possible to determine whether a user exists by requesting the same username twice. If you get the same salt (which you would need to use, in order to keep the server side storage of the password safe) for two calls, you could be sure that the user was real. You could mitigate that by storing the salts you've sent (which results in your user DB being full of junk after a couple of attack attempts) or by algorithmically generating them from the username (which would need to be applied to all users to prevent enumeration by looking for the ones that aren't generated in this way).

The proposed system doesn't really offer any security improvements over a standard username/password login, served over HTTPS, but does increase the attack area, and the information that attackers have about your system. Specifically, they know that the real passwords are hashes, with a known salt - they are a specific length, contain specific characters (probably hex digits), and are valid output for strings containing the salt.

I'd suggest sticking with the tried and tested method of username/password over HTTPS!

  • This answer was exactly what I was after. I assumed that there were no real gain in doing it this way, but I wanted to get my mind straight and understand all the aspects of it. Thank you, Matthew.
    – Alex
    Oct 27, 2015 at 10:39
  • 1
    One more thing: sending a fake salt or a legitimate one will have different timings, exposing you to a timing attack. If HTTPS and a normal login is not enough, try to employ two factor auth.
    – ThoriumBR
    Oct 27, 2015 at 12:18

You must log in to answer this question.

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