10 ms·

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

39 points by gulbrandr 7y ago

jimktrains2 7y ago
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.
als0 7y ago
> 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 https://webauthn.io [2] https://www.w3.org/TR/webauthn-1/ https://www.w3.org/TR/webauthn-1/
- StefanKarpinski 7y ago
  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 http://srp.stanford.edu/whatisit.html
- throw0101a 7y ago
  > 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://tools.ietf.org/html/rfc2945 * https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... It's WebAuthN that's the Johnny-come-lately to the auth world.
zaroth 7y ago
I’ve been following CFRG’s PAKE contest (https://github.com/cfrg/pake-selection https://github.com/cfrg/pake-selection) with some interest. The various algorithms are fascinating and almost, you might say, fairly approachable.
brenden2 7y ago
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/?include_text=1 https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/?inc...
- tialaramex 7y ago
  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.
smy1es 7y ago
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.
- pjbk 7y ago
  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.
ledauphin 7y ago
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... :)
- pjbk 7y ago
  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 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 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.
whoisthisfor 7y ago
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.
- lucb1e 7y ago
  > 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.
  - whoisthisfor 7y ago
    https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/javascript.html 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.
3fe9a03ccd14ca5 7y ago
Wow this sounds amazing — so why isn’t this used everywhere? What’s the downside?
- tptacek 7y ago
  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.
  - prophesi 7y ago
    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.
    - tptacek 7y ago
      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.
      - est31 7y ago
        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.
GhettoMaestro 7y ago
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.
- M4v3R 7y ago
  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.
  - GhettoMaestro 7y ago
    Thanks for clearing that up. I had incorrectly assumed that something other than SRP had come along to fulfill this need - I guess not!

39 points by gulbrandr 7y ago

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.

als0 7y ago

> 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 https://webauthn.io [2] https://www.w3.org/TR/webauthn-1/ https://www.w3.org/TR/webauthn-1/

StefanKarpinski 7y ago
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 http://srp.stanford.edu/whatisit.html
throw0101a 7y ago
> 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://tools.ietf.org/html/rfc2945 * https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... It's WebAuthN that's the Johnny-come-lately to the auth world.

zaroth 7y ago

I’ve been following CFRG’s PAKE contest (https://github.com/cfrg/pake-selection https://github.com/cfrg/pake-selection) with some interest. The various algorithms are fascinating and almost, you might say, fairly approachable.

brenden2 7y ago

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/?include_text=1 https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/?inc...

tialaramex 7y ago
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.

smy1es 7y ago

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.

pjbk 7y ago
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.

ledauphin 7y ago

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... :)

pjbk 7y ago
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 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 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.

whoisthisfor 7y ago

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.

lucb1e 7y ago
> 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.
- whoisthisfor 7y ago
  https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/javascript.html 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.

3fe9a03ccd14ca5 7y ago

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

tptacek 7y ago
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.
- prophesi 7y ago
  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.
  - tptacek 7y ago
    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.
    - est31 7y ago
      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.

GhettoMaestro 7y ago

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.

M4v3R 7y ago
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.
- GhettoMaestro 7y ago
  Thanks for clearing that up. I had incorrectly assumed that something other than SRP had come along to fulfill this need - I guess not!