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.

  • If this is for a website, how are browsers going to compute the Argon2 hashes and big number exponentiation? Oct 30, 2017 at 12:27
  • @ErwanLegrand It's on the server side (password is manually inputted when the sysadmin start the RESTful service). BTW, there is also a Argon2 for Browser ( github.com/antelle/argon2-browser )
    – lakano
    Oct 30, 2017 at 13:13
  • I had thought you used Argon2 (instead of the default salted SHA-1) as the password hashing function in SRP. Oct 30, 2017 at 13:59
  • @ErwanLegrand: No, I respect SRP and Argon2 protocol :)
    – lakano
    Oct 30, 2017 at 14:08
  • Oh, I see! Then I misinterpreted the "even with a good KDF like Argon2" part. I will update my answer accordingly. Oct 30, 2017 at 16:34

1 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.

  • There is no home-made KDF at all. Surely my english wasn't clear enough, it's the number of iterations « t » in the parameter of the Argon2. This number should be set by us, like we want, and we want to set it from 1 to 255 (even if this take 10 minutes to start the service). To known how many round, just XOR each byte of the password, this will result the number to put in the Argon2 setting. The sysadmin password is simply derived with the correct way to use Argon2, but with a number of iterations different based on the password's bytes. My question was on the DB leaks and SRP verifier.
    – lakano
    Oct 30, 2017 at 13:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .