What Is Secure Remote Password (SRP) Protocol and How to Use It? | Hacker News Reader

What Is Secure Remote Password (SRP) Protocol and How to Use It?

medium.com

39 pointsgulbrandr26 comments

Everytime I dig into PAKEs, I find disappointment. If we all used a PAKE from the start of computers, maybe we'd be better off, but that's just because we would have been burned by them a dozen times. Right now the tech is very immature and asking a Dev to use these is essentially asking them to pick a cipher mode and padding for AES. There are no browser native SRP implementations and WebCrytpo doesn't support the primitives. The complexity these add isn't worth it for your vanilla website, IMO.

> There are no browser native SRP implementations and WebCrytpo doesn't support the primitives.

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.

https://docs.aws.amazon.com/encryption-sdk/latest/developer-...

Full Disclosure: My team built this but could be helpful. Doesn't do SRP, just encrypts data.

SRP is a great PAKE (password-authenticated key agreement), it can make certain types of attacks to steal a password (like MITM) nearly impossible.

There's also a newer PAKE that improves slightly on SRP, called SPAKE2: https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/?inc...

A PAKE does mean bad guys don't get the password, but that's not necessarily much of a win if the password was only defending an endpoint which was much more valuable than the password anyway.

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’ve been following CFRG’s PAKE contest (https://github.com/cfrg/pake-selection) with some interest.

The various algorithms are fascinating and almost, you might say, fairly approachable.

> What we needed, in this case, is a strong Zero-knowledge proof (without transferring password) system that does mutual authentication on the client & server.

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.

[1] https://webauthn.io

[2] https://www.w3.org/TR/webauthn-1/

SRP is a remote password protocol. WebAuthN is for public key-based credentials in web apps... so not really related?

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.

[1] http://srp.stanford.edu/whatisit.html

> I've not heard of SRP before, but it seems like it's trying to solve an already solved problem ...

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.

I've always wished that tls-srp was better supported by tools or that srp was a method for http forms that would work in some standardized way.

is anyone aware of a pre-existing Python implementation of this that isn't `warrant` (which appears to be unmaintained as it has several significant issues in its underlying crypto stack)?

I'm tempted to spend some time writing one (AWS Cognito uses SRP), but also have other things I could do... :)

The implementation itself is relatively simple. The most popular Python implementation is Tom Cocagne's pysrp that builds on csrp, his original C implementation: https://github.com/cocagne/pysrp. I used this as a guide to write a pure Python3 implementation of SRP-6a some years ago that I needed for protocol testing on embedded devices, and to internalize how the algorithm worked and the complexity of the calculations: https://bitbucket.org/pbleyer/py3srp.

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.

SRP would be extremely interesting for the web configuration interfaces for IoT devices. We want TLS even locally, but trusting vendor suppled certificates is bad. Implementing SRP on IoT devices would solve these problems, but would need much better support of SRP from the browser vendors.

Actually, that is the reason Apple HomeKit, that is designed mostly for IoT devices (WiFi, BT), uses SRP as part of the authentication process during pairing.

I feel dumb asking this, but does current industry authentication methods (secure channel via TLS) send the actual password, or a derived challenge-response value through the secure channel? I thought it was the latter.

In 99% cases client sends the actual password to the server. If you don't want to send the actual password over the wire then you use SRP (or something similar) mentioned in the original post.

Thanks for clearing that up. I had incorrectly assumed that something other than SRP had come along to fulfill this need - I guess not!

Wow this sounds amazing — so why isn’t this used everywhere? What’s the downside?

It doesn't really solve any problems in the modern web stack, where passwords authenticators are stored in better formats than SRP's and transmitted over TLS to begin with.

Could you elaborate on that? I'm assuming by "password authenticators" you mean the different hashing algorithms one could employ to securely store passwords.

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.

TLS provides much the same protection from eavesdropping, and is practically the universal standard today. Modern password hashes are superior to the augmented authenticator form SRP stores. And you cannot simply "replay" a TLS session. In the modern web stack, the only thing SRP actually accomplishes is the authentication of a TLS connection with a password rather than certificates, which is a fringe use case.

PAKEs are interesting in custom protocols; for a recent and valuable example, see Magic Wormhole. But the reason you don't see them everywhere is that they're just not that useful in web applications.

You treat TLS like a silver bullet. Yes, it's common, but so are TLS intercepting CDNs like Cloudflare which can do a passive attack to find out user passwords. Also, if the password never even enters your network, you are safe from any misplaced debug setting that accidentially logs your passwords (happened to facebook).

The only disadvantage from SRP is that you can't do server side stretching which means you are limited by device concerns like battery power for your stretching parameters.

From what I've gathered from the discussions & links on here:

Our current solution for password authentication is perfectly fine, unless you distrust your CA's.

SRP itself is a bit of a mess, and has gone through a lot of iterations to fix its faults. OPAQUE is probably your best bet. But implementing the protocol seems like overkill for password auth, and is easy to implement improperly.

Such PAKE's will likely prove to have other good use-cases, however, like magic-wormhole.

This sounds about right? Nobody really "trusts" CAs, but the whole WebPKI system that surrounds it is a lot more intricate than most people understand, and we've reached a sort of trust detente with it. The pressure to replace it root-and-branch is mostly gone now, and whatever replaces it, it won't be PAKEs.

I like PAKEs just fine and in particular really like Magic Wormhole.

It isn't used everywhere because it's much too new, nothing like SRP existed when password elements were added to HTML let alone back when the authentication mechanism was added to HTTP itself.

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.

Some problems are listed at https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

Reply on news.ycombinator.com