All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

Post by tptacek » Tue, Dec 15, 2009, 9:36 PM UTC

mattyb wrote: post #110

tptacek wrote: post #84

Earlier quoted context omitted.

Here's a funny thing: every time this comes up, someone asks me if Whirlpool solves the problem. What is it with Whirlpool?

It creates long (512-bit) digests, and: Even a small change in the message will (with an extremely high probability of 1-10^(-154)) result in a different hash, which will usually look completely different just like two unrelated random numbers do. http://en.wikipedia.org/wiki/Whirlpool_(cryptography) I used it for a while, then learned that using a fast hash, even looped plenty of times, is a bad idea for password st…

The second graf describes every cryptographically secure hash, though.

Post by heresy » Tue, Dec 29, 2009, 4:27 AM UTC

ars wrote: post #108

heresy wrote: post #107

Earlier quoted context omitted.

thanks. every time someone uses the password as input to some "secure" hash, i cry inside. why is the password even relevant to a user session identifier? it's not.

And the next time someone logs in as you, and clicks "keep me logged in" - and you have no way to un-log them in, you should also cry inside. If the password is changed, all session identifiers must be invalidated. If it's a session table, delete all entries, if it's a hash - well your hash had better include the password somehow (a hash of the password hash, i.e. the one stored in the db, is fine, as long as changin…

session lifetime is an orthogonal concern to the password.

i just don't see it as a good idea to have the password be one of the inputs to the value of the session identifier in any way, which was my point.

you can handle every scenario you bring up without tying password to session id.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.