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?
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.
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:
I am surprised that people haven't noted that you can and should encrypt the verifier in the db. Typically with large firms the databases are segregated infrastructure. The backup regime of the database servers is also usually deliberately different than the host level backups of the applications servers and web infrastructure. Db backups are usually offsite and on tape with a long retention period. There are also typically different specialists and teams looking after the db infrastructure and backups. When this the case then encrypting the verifier is obviously additional protection from the tapes getting lost by the courier firm moving them offsite.
If you encrypt the verifier then there is the question of where you hold and backup the encryption keys. Large firms like banks have had to solve this problem for their SSL keys and passwords along with other sensitive security configuration. They won't put them onto the same tapes as the db backups. Typically they would have a segregated security network which can manage the front line hosts and have have two hosts (or two dedicated NFS heads) in two data centres on that network mirrored by unison/rsync to backup a copies of the encryption keys and security configuration.
Putting all that together you should have a secure config location or share on the application servers which is excluded from host level backups. Into that location you put a symmetric key read only to your application server user id. The application then uses that to encrypt/decrypt the users SRP verifier as it is saved/loaded to the main db. The keys you backup on segregated hosts in each data centre. If you loose absolutely everything then you rebuild your db from offsite tapes and create a fresh symmetric key. All your uses will no longer be able to login but will simply use your password reset logic to set a new verifier.
