Secure Remote Password protocol
en.wikipedia.org
Secure Remote Password protocol
1–10 of 20 posts
Re: Secure Remote Password protocol
#2This 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.
Re: Secure Remote Password protocol
#3While 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.
Re: Secure Remote Password protocol
#4The part I found interesting was "specifically designed to work around existing patents"
Re: Secure Remote Password protocol
#5While 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 relative…
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.
Re: Secure Remote Password protocol
#6This 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.
It's not ephemeral Diffie-Hellman.
Re: Secure Remote Password protocol
#7While 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 relative…
I thought I remembered 1Password using SRP (https://blog.agilebits.com/2015/11/11/how-1password-for-team...).
I admittedly don't know enough about the underlying cryptography to have an educated opinion, but it seems like they put some due diligence into determining it still provided value.
Re: Secure Remote Password protocol
#8While 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 relative…
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.
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.
Re: Secure Remote Password protocol
#9While 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 relative…
I thought I remembered 1Password using SRP ( https://blog.agilebits.com/2015/11/11/how-1password-for-team... ). I admittedly don't know enough about the underlying cryptography to have an educated opinion, but it seems like they put some due diligence into determining it still provided value.
1Password uses TLS, and SRP inside TLS. If TLS is broken as in Cloudbleed, SRP hopefully still protects the channel - at least against non-active attacks such as Cloudbleed. The security still ultimately relies on TLS. Having not read the document fully, I think those would be against initial registration or in an active MITM allowing password-guessing. I'm looking at page 52 of https://1password.com/teams/white-paper/1Password%20for%20Te....
Re: Secure Remote Password protocol
#10Earlier quoted context omitted.
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.
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…
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.