I'm not following you. The whole point of a password hash is to (1) admit only that one brute-force attack, and then (2) to slow that attack down as much as possible.
SRP gets you (1), but is inferior to every other modern password hash on (2). SRP is better on (2) than other PAKEs (it's an "augmented" PAKE because it tries to slow down brute force), but password hashes have (2) as their whole objective, and total design freedom.
You can combine PAKEs and password hash concepts. But for the purposes of password storage, SRP isn't buying you anything (except for a bunch of possible crypto bugs that will gameover your project).
SRP is a bad call for virtually all projects. Or, maybe a better way to say that is, "if you have to ask, don't use SRP."
> but password hashes have (2) as their whole objective,
Only until that was what people cared about. How long, and how many still, use single-round md5 and sha for password storage?
SRP is an old algorithm -- it could be strengthened significantly with little love. (Similar as to how took a little care from the community for bcrypt, pbkdf2, &c have become the "norm" over md5.)
> SRP isn't buying you anything
SRP is buying you the ability for the server to never have the password, a secret value you're handing someone else!
> SRP is a bad call for virtually all projects. Or, maybe a better way to say that is, "if you have to ask, don't use SRP."
I still feel like you're throwing the baby out with the bathwater. Just because something can be updated and hasn't (like using a weak hash like md5), doesn't mean the core concept is bad (using a 1-way hash function).
SRP gets you (1), but is inferior to every other modern password hash on (2). SRP is better on (2) than other PAKEs (it's an "augmented" PAKE because it tries to slow down brute force), but password hashes have (2) as their whole objective, and total design freedom.
You can combine PAKEs and password hash concepts. But for the purposes of password storage, SRP isn't buying you anything (except for a bunch of possible crypto bugs that will gameover your project).
SRP is a bad call for virtually all projects. Or, maybe a better way to say that is, "if you have to ask, don't use SRP."