Found: Hacker Server Storing 2 Million Pilfered Paswords(arstechnica.com)
arstechnica.com
Found: Hacker Server Storing 2 Million Pilfered Paswords
http://arstechnica.com/security/2013/12/found-hacker-server-storing-two-million-pilfered-paswords/
3 comments
The 5% of users with 'excellent' strength passwords must be kicking themselves. They could have chosen 12345 and been just as secure!
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
I wish I could upvote that 100 times. Password reuse is far more threatening than using bad passwords.
Only 34% bad or terrible?
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).
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).
The Netherlands thing was likely a proxy server for C&C, not a targeted attack on users in that country; they're pretty much all the same IP
The moral of the story seems to be "never give forums a password you use elsewhere".
I'd like the entire web to move to Mozilla Persona, really.
I'd like the entire web to move to Mozilla Persona, really.
I'd like the web to move to SRP [0], or, since you should be using tls if you're accepting passwords anyway, TLS-SRP [1].
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
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
It sounds like a usability nightmare, though. How do you synchronize it between devices?
You just have to enter your username/password per device, just as you do now? I don't understand the question. How do sync currently?
Even with persona you would need to be logged into your email provider on different devices.
Even with persona you would need to be logged into your email provider on different devices.
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.
[1] http://en.wikipedia.org/wiki/Password-authenticated_key_agre...
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...
This is fantastic, why isn't it used anywhere? It's silly to do traditional password auth when this exists. Thanks for the heads up.