What steps can you take to make offline cracking of SRP harder?

Question

In the aftermath of the Blizzard hack, what steps can I take to make offline cracking of SRP more difficult?

My question assumes that your database is already gone and that you implemented SRP more or less properly.

Related: How secure is the SRP that Blizzard uses to protect passwords?

Answer 1

In SRP, the server stores a password-derived token, which can be used to guess the password in an offline dictionary attack (attackers tries potential passwords until a match is found). This is not a flaw of SRP: the server necessarily contains some similar password-derived data, regardless of the used authentication protocol. The magic of SRP is that no other place in the protocol yields such a password-derived data (even if the attacker tries to impersonate the server). But if the server itself is compromised (all its secrets are known to the attacker), then an offline dictionary attack is possible.

Strengthening this token involve the usual tools, i.e. salts and iterations (see bcrypt). In practice, this means that the output of bcrypt is used as "password" in SRP.

Answer 2

There are two options. SRP computes a hash of the user's password, then exponentiates it, and stores the result. Option 1: You can replace that hash with a "slow hash" -- I recommend PBKDF2. Option 2: You could pre-hash the password with PBKDF2, then use the result as before. I provide a detailed proposal in my answer to Can I use a key-derivation-function as the hash function H in SRP?; please see my answer there for the detailed mathematics. Either of those options will solve your problem.

Related:

• How realistic is a dictionary attack on a secure remote password protocol (SRP) verifier?
• How secure is the SRP that Blizzard uses to protect passwords?
• Does the hash change the security of the Secure Remote Password protocol?
• Implementing Secure Remote Password: Constructing the verifier