[spizzo]

So what do you do past this point? I know you can probably rough out how much time it would take to find hash collisions and ask as your users to change their passwords before that amount of time elapses, but past that point, can't you no longer assume that it's the actual user logging in to change their password?

[sveiss]

We performed a forced password reset on the users with compromised hashes. The old password will not work on Scribd, and those users will need to go through the password reset flow to regain access.

[spizzo]

Ah ok. I was wondering how you verified the users' identity if the password was compromised. That makes sense, thanks!

[kpumuk]

We have reset passwords for all affected users. Hashes that got leaked are not useful now.

[icebraining]

Well, that assumes people aren't reusing those passwords.

[beachstartup]

http://en.wikipedia.org/wiki/Salt_(cryptography)

[harshreality]

Salts make cracking a list of N password hashes take roughly N times as long, but if a password is cracked anyway (because it's common and/or because the hash is not using very many rounds, or because an attacker only cares about one particular account), and the password is reused elsewhere, the fact that it was salted doesn't matter anymore.

GP is right; if owners of the leaked accounts [email, hash] pairs are reusing passwords, the leaked hashes are potentially useful even though scribd has reset them. They're simply not useful for logging in to scribd.

[beachstartup]

yeah if you simply know what a password is, of course it's compromised, but you're not supposed to easily break a salted hashed password.

[icebraining]

Salts only really protect against rainbow tables; if the attacker is willing to use a dictionary or brute force attack against a single password, they're not of much use.