0

Let's say i have a scenario when the user salt is required in client side before login,

the user obtains the salt by this url http://my-api.example/get-salt/userid

that url should return a salt for any user without login or authorization, should this be a problem or cause some security risks ?

Note: that each user has a unique salt

Improve this question
5
  • 1
    Why would you make the salt accessible to the user? It's not something the user needs at all.
    – user163495
    Commented Nov 27, 2019 at 9:06
  • Need it to calculate hashes on client side
    – user212160
    Commented Nov 27, 2019 at 9:08
  • @MechMK1 also i got that idea from this article, Schema 2, ithare.com/…
    – user212160
    Commented Nov 27, 2019 at 9:13
  • You could also derive the salt from the userid, e.g. concatenate it with a constant value specific to your site to make it globally unique. That way you can avoid the request entirely. (Though consider the effects on security: while a salt merely needs to be unique, making it secret and unpredictable adds another hurdle for attackers. It all depends on your use case.)
    – Marc Schütz
    Commented Nov 27, 2019 at 13:58
  • @MarcSchütz Thank you for your comment !, it does make more sense tbh, now that i have thought about it, adding constant padding to the user email and then hashing them using sha256 and that output could be used as a salt.
    – user212160
    Commented Nov 27, 2019 at 14:29

1 Answer 1

Reset to default
0

There are two issues here:

Firstly, you need to avoid providing an oracle for "does this user exist in the system". That means you need to provide a value whether the user exists or not. Furthermore, this value must be consistent for a given userid (otherwise the attacker asks multiple times, and if they get the same answer every time, they know the user exists). On the other hand, it must not be possible for the attacker to calculate the fake salt given the user id. This means you need to generate a secret key for each installation, and the fake salt is generated by encrypting the userid with the key (or calculating the HMAC, or similar). As noted in a comment, you also need to make sure that returning a real salt or a fake salt take the same length of time (otherwise the time taken can provide an oracle to tell whether the user exists or not).

Secondly, this is a cheap request for the attacker to issue, whereas the server is going to need to go to the database to see if the user exists, and if not, encrypt a value. You will need some mechanisms in place to avoid this being a potential DoS vector.

Final thought: I presume you are doing this, in order to offload the computational effort of hashing the password onto the client. This is fine, and in the right situations, sensible. However:

You must make sure you are using the browser to calculate the hash in native code, rather than javascript. If you don't, the attacker with a leaked database (who is probably doing the hashing in native code on multiple GPUs) just has too big a performance advantage.

In addition, you need to make sure that you do one more round of hashing on the server and then compare the result with what is in the database. If you don't, and the database ever leaks, the attacker will be able to log in as the user just by replaying the value from the DB.

Improve this answer
4
  • 1
    Re. "the server is going to need to go to the database to see if the user exists, and if not, encrypt a value"... to avoid "being an oracle" (as to whether a user exists), the OP would need to make sure both processes (lookup, generate "fake" salt) take roughly the same time.
    – TripeHound
    Commented Nov 27, 2019 at 11:08
  • Re: "you need to make sure that you do one more round of hashing on the server and then compare the result with what is in the database. If you don't, and the database ever leaks, the attacker will be able to log in as the user just by replaying the value from the DB" This is the most important issue here, IMHO. When the user submits the hashed password to you, the hashed password IS the password for your system. If it leaks the attacker has the password to access your system.
    – CristianTM
    Commented Nov 27, 2019 at 17:37
  • Note that unless the salt doesn't change when the user changes password, this could still be used as an oracle for whether the user exists as a real user salt will probably change occasionally while a fake one won't. It also leaks information on when the user changed its password.
    – user2313067
    Commented Nov 28, 2019 at 16:27
  • @user2313067 Well, we don't change the salt (I'm not sure how bad that is), but even if we did, users change passwords so rarely that it isn't a very useful oracle to an attacker - typically finding the names of real users is a very early stage in a reconnaissance .
    – Martin Bonner supports Monica
    Commented Nov 28, 2019 at 17:05

You must log in to answer this question.