This is flatly wrong. SRP stores serverside verifiers that are derived from plaintext passwords. Stealing an SRP verifier is equivalent to stealing a password hash.
The math for the brute force attack on SRP verifiers is slightly more elaborate than that of a salted hash (it involves a modexp), but is significantly cheaper than bcrypt. Using SRP is, from the perspective of a compromised server, worse than using bcrypt.
You may have become confused about SRP because Thomas Wu goes through some effort to explain how SRP is resistant to dictionary attacks. If so, you've mistaken which specific dictionary attacks he was talking about: previous challenge-response protocols were dictionary attackable off the wire, meaning that a passive attacker could grab the challenge-response sequence and crack that as if it was a password hash.
> This is flatly wrong. SRP stores serverside verifiers that are derived from plaintext passwords. Stealing an SRP verifier is equivalent to stealing a password hash.
I'm not wrong, you're just missing the point. The derivation process happens on the clients machine, so they get to 'chose', and verify, how it's performed, and can therefore ensure the KDF is extremely strong. The server doesn't need to know how it's strengthened and cannot, in fact, even discern if the verifier it sees is derived from a random value or through some purely deterministic process.
The objective here is to stop trusting the server with our passwords because they're prone to being lax, not prevent every conceivable technical attack from supercomputers from, and algorithms known only to, the NSA.
> Using SRP is, from the perspective of a compromised server, worse than using bcrypt.
First of all, you can use Bcrypt inside SRP, so the password cracking route is a wash. It's the same, by definition. Secondly, I never said SRP6a as currently specified is what we should use. I said a protocol like SRP and even put emphasis on like. Elliptic curves are the way to go for compactness and speed these days.
An attack on the verifier is going to be vastly less feasible than attacking the KDF. The current best algorithms for breaking a good asymmetric verifier would be many orders of magnitude more complex than just bruteforcing any real world password input, even if it's heavily strengthened with Bcrypt or Scrypt.
100ms of PBKDF2/SHA-256 on a modern server CPU gives you maybe ~20 bits of strenghening on top of a weak ass ~30-40 bit password. Scrypt will give you maybe ~16 more bits, with a sigificantly higher hardware (memory) cost. Total, that's still a long way off the ~120 bits achievable trying to solve the DLP on an elliptic curve. In the end, cracking that verifier is more expensive.
If the client can choose any mechanism it wants to create a verifier, the system you propose is (a) not SRP, as you concede, and (b) really just a clunkier way of doing 2FA†.
I like 2FA. Most people like 2FA. If you had started out by saying "passwords suck, the answer isn't bcrypt, it's 2FA", I'd have agreed with you. Instead, you said "SRP", which simply doesn't solve the problem you're purporting to solve.
† To see why: imagine your SRP-derived client-specified verifier generation protocol was adopted: you'd have three mainstream implementations (NSS, Safari, and Internet Explorer) based on passwords all of which would have the same security as simply doing scrypt on the serverside; the additional "win" of your proposal would be the oddball clients that did something other than scrypt, where SRP would give them a challenge-response framework they could layer their system on. Awesome. That's what 2FA systems do. And they don't rely on passwords at all.
If you're going to reimagine all of HTTP authentication, why on earth would you drag passwords along?
Yes, in the same way that simply using scrypt would.
But, of course, the point isn't that SRP is a weak construction. The point is "client side stretching", whatever that was intended to mean, has nothing to do with the problem of losing a database of password "verifiers", be they plaintext, salted hashes, password hashes, or SRP v-values.
The math for the brute force attack on SRP verifiers is slightly more elaborate than that of a salted hash (it involves a modexp), but is significantly cheaper than bcrypt. Using SRP is, from the perspective of a compromised server, worse than using bcrypt.
You may have become confused about SRP because Thomas Wu goes through some effort to explain how SRP is resistant to dictionary attacks. If so, you've mistaken which specific dictionary attacks he was talking about: previous challenge-response protocols were dictionary attackable off the wire, meaning that a passive attacker could grab the challenge-response sequence and crack that as if it was a password hash.