How do SRP (and PAKE generally) protect against verifier leak

Question

I have been reading into PAKE protocols, specifically starting with SRP RFC2945

The gist of the requirement on the server is that the server saves triplet (username, verifier (v), salt (s)) in the credentials table.

Where verifier v = g^x % N (the ^ operator is the exponentiation operation) and x = SHA(<salt> | SHA(<username> | ":" | <raw password>))

Now during the authentication dance, the client obtains the salt (s) from the server and computes the same verifier (v) that the server is using. It can compute this value because it collects the username and password from the user themselves.

In the next few steps the client can subtract the component v from the servers challenge B = (v + g^b) % N and arrive at a key derived from S.

Client: S = (B - g^x) ^ (a + u * x) % N

My question is that if someone hacks my database and dumps the credential table with (username, verifier (v), salt (s)) they immediately have access to all verifiers for each username. Then what stops them from using the obtained verifiers to imitate a client and complete the client side authentication steps? So instead of computing the verifier (v) from the real username and password, they can simply use the verifier obtained maliciously from the server to continue the client side computation and arrive at the same key as the server.

i.e. In my reasoning if my server is hacked and credentials leaked the end result is no better than if I were saving plain text passwords.

Disclaimer: I admit I do not understand fully the maths but generally the concept that such crypto protocols rely on the property of exponents that (g^a)^b = (g^b)^a = g^ab

Answer 1

Even if an attacker breaches the server database, and obtains the userid (u), verifier (v), and salt (s) for a client, the attacker would not be able to use this information to login as that client.

See https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol. Step 4 is where the client computes the client session key, as follows:

S_c = pow(B - k * pow(g, x, N), a + u * x, N)   [eq 1]

The verifier was previously calculated as:

v = pow(g, x, N)   [eq 2]

So, knowing the verifier, the attacker could re-write eq 1 as:

S_c = pow(B - k * v, a + u * x, N)   [eq 3]

B was previously sent from the server, k and N are constants known to both parties, a is computed on the client side, the client has everything he needs to calculate u, v was obtained from the server in the breach - but what about x? Before calculating the client session key, the client must first calculate x as follows:

x = H(s, I, p)   [eq 4]

where s is the salt (obtained from the server in the breach), I is the user id (also obtained from the server in the breach) and p is the password.

Without the password, the attacker cannot compute x, therefore the attacker cannot compute the session key. Without the session key, the client cannot authenticate with the server. So knowing u, v, and s for a client is not enough for an attacker login as that client. The attacker must also know x, which is calculated from the password.

However, x is equivalent to the plaintext password. This is why the client should not store x.