There is a recommanded solution to protect SRP verifier to be used if the DB is leaked?

Question

We working on a new website we would like to use SRP protocol. So the salt and verifier are sent to the server, and in theory the server store them like that in a database. If the DB is leaked, attacker could surely brute-force a user password and check with the verifier/salt (even with a good KDF like Argon2). We would like to prevent this, there is a recommended solution please?

My current solution:

On RESTful service start, a master password is manually inputted, then hashed with Argon2 multiple time (XOR each password's byte to get the number, up to 255). This master password hash is used to encrypt any sensitive information with AES-GCM before storing them in the DB (salt, SRP verifier).

With this method, if the DB is leaked, even with source code or harddrive, the attacker can't exploit SRP verifier. The only attack I have in mind, would be to install a rootkit and to dump memory to found the master password.

Answer 1

As with databases of password hashes, the traditional approach to prevent dictionary based attacks is to make computing hashes (or in this case verifiers) from passwords costly enough.

In the case of SRP, the obvious way to do this is to choose a group which is large enough. (In any case, it must be large enough to resist cryptanalysis, as with RSA or DH.)

Obviously, increasing the size of the group will also slow down both clients and servers.

Another possibility is to replace SHA-1 with another hash function as is suggested in section 3.2 of RFC 2945. The salted SHA-1 construct used in SRP-SHA1 can be replaced by another message digest, or by HMAC or by a password hashing function.

In my opinion, using a good password hashing function such as Argon2 or BCrypt or PBKDF2 instead of SHA-1 makes sense. Doing this increase the cost of dictionary attacks without having any impact on server performance. (Client performance is impacted though.) On the other hand, this does not improve resistance to cryptanalysis.

SRP is designed to protect passwords in a threat model which assumes an attacker can gain access to the memory of the server. Thus, SRP is designed to be secure in a context where an attacker would have access to your master password.

This above also means SRP actually competes with password managers, the later being a more widely deployed solution. SRP is mostly useless if your users already use password managers with a unique password for each site.

Encrypting stored verifiers is essentially the same as "peppering" a password database. This adds quite a lot of complexity. Whether this improves the security of the system is not obvious.

This only makes sense if you assume the attacker has access to the database but not to the server (while using SRP only makes sense if you assume the attacker has access to the server), your master password has good entropy and your encryption code is properly written (IVs are properly generated...)

Regarding your usage of Argons2, you should make the parameters fixed: use as much memory and processing power as you can afford. Do not make the parameters depend on the password.