I am attempting to use SRP to verify clients when they authenticate with a webserver, so that the password is never sent over the wire.
Looking at the SRP procedure, when a client registers with the server it sends
s (salt), and
I (the username or identifier) to the server who stores these values. However, it is stated that:
[The salt] could be chosen by either side but is done by [the client] so that [it] can register I, s and v in a single registration request.
If the salt can be chosen by either the server or the client, then we can just assume the server generates it.
When the client later tries to authenticate with the server, the client sends
I and the server responds with
s. Then the client uses
s and other data to preform the proof of password.
My question is, why is
s static? Why does it need to be stored at all?
The salt is sent out to whoever requests it, and because of this an attacker could attempt to build a targeted rainbow table by requesting the salt of a specific user. This is brought up in this question, at bullet point #2.
Wouldn't it provide more security for the server to randomly generate a salt upon a
ClientHello message? On each separate request, a different salt would be sent, preventing the attacker from being able to compile a targeted rainbow table. Additionally, the salt wouldn't be stored on the server, which would make the information even less useful in the event of a data breach.
Notably, this method might open up an attack vector where the attacker continually initiates the authentication procedure until the server responds with a favorable salt. However, if the entropy of the salt
s is sufficiently large this would be infeasible. Additionally, the server could throttle the number of authentication attempts per username
I, so that an attacker couldn't run this attack in parallel with a botnet
- For example: After initiating an authentication attempt for
I, the server would not respond to subsequent attempts to authenticate as
Iwithin a time frame of say, half a second.