

Found: Hacker Server Storing 2 Million Pilfered Paswords - protocolon
http://arstechnica.com/security/2013/12/found-hacker-server-storing-two-million-pilfered-paswords/

======
joosters
The 5% of users with 'excellent' strength passwords must be kicking
themselves. They could have chosen 12345 and been just as secure!

~~~
shawabawa3
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

~~~
JonSkeptic
I wish I could upvote that 100 times. Password reuse is far more threatening
than using bad passwords.

------
dspillett
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).

~~~
girvo
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

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

~~~
jimktrains2
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](http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)

[1] [http://en.wikipedia.org/wiki/TLS-SRP](http://en.wikipedia.org/wiki/TLS-
SRP)

~~~
StavrosK
It sounds like a usability nightmare, though. How do you synchronize it
between devices?

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

~~~
StavrosK
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?

~~~
KMag
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...](http://en.wikipedia.org/wiki/Password-
authenticated_key_agreement)

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

