Does providing non existant users with fake salts prevent user enumeration?

Question

Background

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.

Question

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?

Concerns

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

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!