
What Is Secure Remote Password (SRP) Protocol and How to Use It? - gulbrandr
https://medium.com/swlh/what-is-secure-remote-password-srp-protocol-and-how-to-use-it-70e415b94a76
======
whoisthisfor
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
> 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
[https://docs.aws.amazon.com/encryption-
sdk/latest/developer-...](https://docs.aws.amazon.com/encryption-
sdk/latest/developer-guide/javascript.html)

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

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

~~~
tialaramex
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.

------
zaroth
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.

------
als0
> 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
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)

------
jimktrains2
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.

------
ledauphin
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
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.

------
smy1es
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
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.

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

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

~~~
tptacek
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
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
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
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.

~~~
prophesi
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.

~~~
tptacek
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.

