
Secure Remote Password protocol - DorothySim
https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
======
tprynn
While this is interesting historical reading, SRP is badly outdated and should
not be used for any newly built systems. It has a lot of non-obvious failure
modes around parameter handling and offline password cracking that have broken
the authentication mechanism in every implementation I've seen in the real
world (new implementations, not when using large packages such as OpenSSL).

Furthermore, PAKEs are of relatively limited utility; in almost every
situation you could use a PAKE, there is a better, more battle-tested
alternative. You will be much less likely to have complete authentication
bypass in your system if you use mutual TLS rather than a PAKE.

If you have to use a PAKE, use a reviewed implementation of SPAKE2. Oh wait,
there aren't any. Don't use a PAKE.

~~~
tptacek
A nit: even compared to some recent designs, SRP is pretty thoughtful about
offline password cracking. It's not as expensive to crack as a real password
hash, but far more expensive than other PAKEs.

~~~
tprynn
I haven't read enough about the other PAKEs to know what offline attacks look
like there, but the fact that they are endemic to PAKEs is a total footgun.

For example, one implementation of SRP I looked at used 8-digit codes (e.g.
12345678) to connect new devices to a network. Eight digits was enough to
prevent brute-forcing by repeatedly sending codes to the server, but not
enough to prevent an attacker from MITMing the connection and brute-forcing
the code offline, because the server was using a bad RNG.

~~~
tptacek
Wait, what's the brute-force attack you're contemplating here? I'm thinking of
the attack where you've compromised the servers and stolen the verifiers.

~~~
tprynn
Looking back at my notes, I think my earlier comment was misleading. The
offline brute force was due to an insecure random number generator, which
allowed an attack against B to recover b (and from there crack the 8 digit
code). So, uh, ... I'm wrong on the internet. I think we've talked about this
attack before actually :P

~~~
tptacek
Ok, that makes more sense! There are some pretty huge systems that would be
very, very broken if the attack you accidentally described was viable. :)

I agree with you that SRP is worth avoiding.

------
alfalfasprout
This sounds like ephemeral diffie hellman. Is that still protected by patents?
I wouldn't think so seeing we've had robust implementations in openssl for a
long time now.

~~~
tptacek
It's not ephemeral Diffie-Hellman.

~~~
DorothySim
According to this [0] they are related ("SRP is related to Diffie-Hellman.").

[0]:
[http://web.archive.org/web/20130407190430/http://chargen.mat...](http://web.archive.org/web/20130407190430/http://chargen.matasano.com/chargen/2007/9/7/enough-
with-the-rainbow-tables-what-you-need-to-know-about-s.html)

~~~
tptacek
They're related in that the derivation of session secrets is done through a
simple modular exponentiation. Pretty much nothing else, from the generation
of keypairs to the selection of groups to work in to the way parameters have
to be checked, are the same.

------
throwaway2016a
The part I found interesting was "specifically designed to work around
existing patents"

~~~
cvwright
Specifically, Bellovin & Merritt's Encrypted Key Exchange (EKE).

[https://en.wikipedia.org/wiki/Encrypted_key_exchange](https://en.wikipedia.org/wiki/Encrypted_key_exchange)

The patent is expired now though.

