I recently had a "excellent" password compromised. The lesson: bad passwords that aren't shared between accounts are better than good passwords that are shared
It would appear that the average person in the Netherlands do better at password security than the people I experience (no, you can't just use your own middle name, even if you replace the i with a 1).
If I'm not misunderstanding the protocol, after the initial registration/authentication, you need to store the session key to your device so you can prove you have it in subsequent attempts. You have to somehow move that key to all your devices, no?
You're misunderstanding the protocol. SRP is what's known as an "augmented password authenticated key exchange" (Augmented PAKE) protocol [1]. A PAKE protocol is one where the result of the protocol is the client and server ending up with a shared ephemeral key at the end of the protocol, if they both know the shared secret. The "Augmented" part means that the client and server actually have different secrets, and the server-side secret cannot be used to perform the client side of the protocol. There are other Augmented PAKE protocols. The chief advantage of SRP is that it is believed to be unencumbered by patents.
The non-ephemeral key that you have to "somehow move to all of your devices" is just a salted hash of your password, and the server sends the salt in the clear every time. Either the client just needs to ask you for your password every time, or your device needs to ask for your password once and then remember the salted hash.
Think of SRP as a modified Diffie-Hellman key exchange/agreement protocol where the client and the server each have an additional secret that's necessary for the shared secret to come out right. In addition, stealing the server-side secret doesn't allow one to perform the client-side of the protocol, assuming the DH problem is difficult. (In other words, the server-side secret isn't password-equivalent.)
Each time you log in, the client and server end up with a unique ephemeral encryption key. Furthermore, the protocol has forward secrecy, so (presuming the DH problem is difficult), even if the secret police come and beat your password out of you and have sniffed all of the network traffic into and out of the server, old session keys cannot be recovered.
Really, the only downsides to SRP are
(1) the standard is defined only with a 1024-bit modulus. This needs to be updated to 4096-bits to stay ahead of the curve.
(2) the server-side secret (stored where you'd normally store password hashes) is as big as the modulus, so 128 bytes or 171 base64 chararcters
(3) there have been attempts to create elliptic-curve variants of SRP that would solve both of the above, but all of the EC SRP variants I've seen have later been shown to leak small amounts of information about the password
If someone comes up with a non-leaky version of SRP based on discrete logs in Curve25519 and using scrypt as the underlying password hash function, then there's very little excuse for continuing to store traditionally salted passwords as standard operating procedure. Note that as a backwards compatibility fallback, the server-side SRP secret can be treated as just a fancy password hash, since the password and salt are sufficient to derive both the client-side and server-side secrets.
12 comments
[ 0.24 ms ] story [ 28.2 ms ] threadIt would appear that the average person in the Netherlands do better at password security than the people I experience (no, you can't just use your own middle name, even if you replace the i with a 1).
I'd like the entire web to move to Mozilla Persona, really.
This way noöne, not even your email provider, actually has your password.
[0] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
[1] http://en.wikipedia.org/wiki/TLS-SRP
Even with persona you would need to be logged into your email provider on different devices.
The non-ephemeral key that you have to "somehow move to all of your devices" is just a salted hash of your password, and the server sends the salt in the clear every time. Either the client just needs to ask you for your password every time, or your device needs to ask for your password once and then remember the salted hash.
Think of SRP as a modified Diffie-Hellman key exchange/agreement protocol where the client and the server each have an additional secret that's necessary for the shared secret to come out right. In addition, stealing the server-side secret doesn't allow one to perform the client-side of the protocol, assuming the DH problem is difficult. (In other words, the server-side secret isn't password-equivalent.)
Each time you log in, the client and server end up with a unique ephemeral encryption key. Furthermore, the protocol has forward secrecy, so (presuming the DH problem is difficult), even if the secret police come and beat your password out of you and have sniffed all of the network traffic into and out of the server, old session keys cannot be recovered.
Really, the only downsides to SRP are (1) the standard is defined only with a 1024-bit modulus. This needs to be updated to 4096-bits to stay ahead of the curve. (2) the server-side secret (stored where you'd normally store password hashes) is as big as the modulus, so 128 bytes or 171 base64 chararcters (3) there have been attempts to create elliptic-curve variants of SRP that would solve both of the above, but all of the EC SRP variants I've seen have later been shown to leak small amounts of information about the password
If someone comes up with a non-leaky version of SRP based on discrete logs in Curve25519 and using scrypt as the underlying password hash function, then there's very little excuse for continuing to store traditionally salted passwords as standard operating procedure. Note that as a backwards compatibility fallback, the server-side SRP secret can be treated as just a fancy password hash, since the password and salt are sufficient to derive both the client-side and server-side secrets.
[1] http://en.wikipedia.org/wiki/Password-authenticated_key_agre...