With SRP, you're protected from replay attacks, and from eavesdropping. You also don't need to trust the server's certificate, which can be a problem with obscure IoT devices.
For icing on the cake, you can do client-side hashing of the password before running it through the protocol so that even if the attacker took over the server, they would have just as difficult of a time running an offline dictionary attack.
The downside for that last part is how underdeveloped the WebCrypto API currently is. You wouldn't be able to use bcrypt or the like without needing a third-party library.
Also none of Tim's toy hypermedia system is built from state of the art components. HTTPS is a retrofit, graphics are an afterthought, the reason Tim succeeded is that since this was not his academic field he felt confident to do a half-arsed job whereas people who'd been doing this for years wanted to actually solve the hard problems first.
Why we didn't suddenly wake up in say 2000 and switch to SRP? Because for every crap site they already had a crap password system, no obvious incentive to get a good one. And as another poster points out this particular PAKE is/was patented which always stifles usage.
This. Similarly, I looked into the web crypto API yesterday to see if I could use argon2 yet. Nope, and also not scrypt, so no memory-hard standards at all. Heck, it doesn't even do bcrypt. Not sure why I hoped for anything else, but the best thing it has to offer is PBKDF2.
Unless browsers start to support the things actually in use, I guess in-browser crypto is doomed and everything will remain server side or consist of homebrew javascript implementations.
Full Disclosure: My team built this but could be helpful. Doesn't do SRP, just encrypts data.
I've not heard of SRP before, but it seems like it's trying to solve an already solved problem, and in a seemingly more complicated manner. The W3C's Web Authentication spec[1,2], on the other hand, looks very promising, and I'm hoping all browser vendors will get behind it once it's finished.
SRP is a "perfect" remote password protocol: it reveals no information about your password, not even a salted secure hash of it, which could be brute forced or cracked. The only information that is gained by the server is whether the client has entered the correct password or not. It's somewhat surprising that this good of a password protocol even exists. There are others with similar properties, but it still surprises me.
The main reason I suspect that SRP didn't become widely used much earlier is that it was originally patented. The patent appears to have expired in 2015, so it seems like one can use the protocol for free now. The text on the Stanford SRP page [1] reads as though it was always designed to be open and freely usable, but that's not my recollection from reading about it years ago. I recall reading about the protocol (maybe 15-20 years ago), getting really excited and then getting to the part where it was patented and getting equally disappointed.
SRP came out in 2000:
* https://tools.ietf.org/html/rfc2945
* https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
It's WebAuthN that's the Johnny-come-lately to the auth world.
There's also a newer PAKE that improves slightly on SRP, called SPAKE2: https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/?inc...
If the PAKE keeps bad guys who break into the Crab Positivity Forum from learning a password which I also used for my GMail that's great, maybe they post anti-Crab propaganda and get me banned, but I'll live. Whereas if my bank uses it and bad guys empty the account but thanks to a PAKE don't learn my password in the process I'm gonna think that is a very cold comfort.
I'm tempted to spend some time writing one (AWS Cognito uses SRP), but also have other things I could do... :)
That being said, I would never use plain vanilla Python for cryptography in a system that needs to be strongly secured. Too many side channel and timing attacks possible where you can replicate or estimate the state of things locally once you know the other side is running a Python VM.
The various algorithms are fascinating and almost, you might say, fairly approachable.
