What can I do, if my SRP password verifier was stolen?

Question

I've got a system that works like this:

Client -> Server: authenticate me

Server -> Client: ok, you are authenticated

Server -> Client: now do some computations for me

And I use SRP as an authentication mechanism. Everything works fine, until somebody steals my password verifier. If the password verifier is stolen, the attacker is able to work as a server, because both server and attacker have the same amount of data for clients authentication.

Client -> Attacker: authenticate me

Attacker-> Client: ok, you are authenticated, because I have verifier

Attacker-> Client: now do some extremely heavy computations, so I can burn your computer

What to do in this situation? Can I invalidate the stolen verifier or something?

I thought I can use this formula to compute verifier: $g^{hash(x|\text{salt}|\text{invalidation date})}$

So server will be forced to send invalidation date first, so client will know if verifier is too old. But this is very hard to implement, because of time synchronization.

And one more option. Client may store server's public key in configuration file as well as sever's host and port. Then client can send server some challenge to encrypt. But I don't know is it good solution or not.

Answer 1

In SRP, if the server-side password verifier leaks, that does not immediately allow login to the server. That "only" exposes the password to brute force search in a dictionary (each password test essentially does what the normal client and server do at login, only at high speed and with speedups because the server's challenge can be fixed). The attack's difficulty depends mostly on the password quality; and on if the password first goes (on the client side) thru some entropy-stretching (PBKDF2 or modern alternative), which unfortunately is not part of SRP (no mention of a slow pre-hash of the password with some standard-defined salt).

Thus if the server database with SRP password verifiers leaks, the passwords are at least as exposed to brute force search as with standard password hashing methods, and typically much more. Short of changing all the passwords, nothing can be done to that.

Said leak however does not compromise confidentiality of sessions encrypted earlier using SRP-negotiated session keys.

Update: I now understand that the question uses SRP password authentication to protect the client from a bogus server when the password verifier is secret. I was told and accept this works.

The adversary with the password verifiers can act exactly as the server (assuming the clients does not otherwise authenticate the server). I do not see a remedy that re-establish server authentication after password verifier loss, short of changing all the passwords, or authenticating the server by a method other than SRP, or changing SRP in a way that requires storage on the client.

---

SRP is not without virtue; in particular, if it was enforced on the client side (which is rare), and if it came with slow password hash (which is not standard), it would be safer than current practice (establishing a TLS tunnel with server authenticated using a certificate, then sending password in that tunnel); in particular making it impossible that impersonating the server at a single login attempt (by way of a forged certificate or an inattentive user not using https) directly leaks the password to an attacker.

Answer 2

You need to add another step, before the client SRP login, to verify the server to the client. You can use SRP to do this by reversing the client/server roles and have the server create private secret z, public verifier Z, to login to the client using x=z and v=Z.