Comment by psycr
14 years ago
Every single time this happens, I immediately wonder: "what was the hashing scheme?"
Like many others before it, Scribd disappoints by not addressing this question. Instead we get this:
Even though this information was accessed, the passwords stored by Scribd are encrypted (in technical terms, they are salted and hashed).
How long was the salt? AFIK, MD5 hashes with an insufficiently long salt can be bruteforced with open sourced CUDA setups.
Further, how did they determine the following?
Most of our users were therefore unaffected by this; however, our analysis shows that a small percentage may have had their passwords compromised.
We use scrypt for passwords hashing. This is modern hard to crack password hashing algorithm.
We do have database access logs, so it was pretty straightforward to identify which users were affected.
You should add this. Savvy people will be positively surprised to see a company actually caring about doing password authentication right.
That is awesome. You should feel comfortable telling people this; it puts you way ahead of the game.
Thanks for clarifying, good to see you're using a decent hashing algorithm :)
I'm still a little unsure of how you are able to know some users had their password compromised. Is it a simple case of finding successful log in attempts from the same IP address as attack?
Compromised != Hacked. To clarify: no accounts were accessed by the hackers, but small amount of account records have had passwords encrypted with outdated algorithm (basically SHA1 + salt), so we preemptively reset their passwords and sent out emails to all affected users.
This is how we define "compromised" - people which had their passwords hash with old algorithm, which is relatively easy to crack.
7 replies →
http://www.scribd.com/password/check thank you for this. now I can run a list of emails against this to see who has scribd account
I just put in a bunch of fake email addresses and they all returned with "Good news - your password has not been compromised." I think the only confirmation that youd get of an existing account is if the password was compromised.
They can modify it to simply say whether your account was compromised, regardless of whether you have an account (ie, if no account -> not compromised).
3 replies →
That's good to hear. As a future suggestion to anyone else who finds themselves in this unfortunate situation - including some technical granularity in your press release can go miles in offering reassurance to your technical audience/users.
Why? Honestly asking: what difference does this have on the end result? Now that you know they are using scrypt, how will that impact your actions?
You could say that this has a bearing on whether you continue to use the service, but if that were the case, wouldn't it be better to suggest that all services provide this information up front?
3 replies →
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?
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.
1 reply →
We have reset passwords for all affected users. Hashes that got leaked are not useful now.
5 replies →
Can I suggest you also share what parameters you use with scrypt? Scrypt is parametric and you can choose weak or strong choices for parameters depending on how long you want to spend validating passwords.
»What hashing scheme do you use?« does not matter for most users.
Most users use weak passwords and a substantial part of this passwords is easy to recover using a dictionary attack. It does not really matter if you use MD5, SHA1, SHA2, HMAC, PBKDF2, bcrypt, scrypt or whatever, nor does it matter if you use no salt, the same salt for all users or a unique salt per user. Even for PBKDF2, bcrypt and scypt the cost factor will - for practical reasons - usually not be large enough to mitigate dictionary attacks using a few thousand of the most common passwords. Therefore weak passwords are compromised regardless of the used hashing scheme. And because especially users with weak passwords tend to reuse the password for different accounts many other accounts are compromised, too.
A user caring about security will not reuse passwords for different accounts and this alone reduces the impact of the event by a huge amount. Further a strong password alone makes it very unlikely that attackers will recover the password even if only unsalted MD5 is used for hashing. Therefore - unless the password is stored in plain text - it is highly unlikely that an attacker will be able to access an account protected by a strong password.
I definitely don't want to argue that using unsalted MD5 is okay - it is not - but for the average user the difference between a weak and a strong hashing scheme is not as large as one would naively expect. Strong hashing schemes will especially protect users using infrequent dictionary words or medium length hard passwords because the additional computation power required to perform a dictionary or brute force attack will force the attackers to use smaller dictionaries and shorter passwords.
Finally storing passwords may benefit from security through obscurity. If the attacker is unable to figure out the used hashing scheme he will be unable to perform a dictionary or brute force attack. This does not mean everyone should come up with there own hashing scheme - this would do MUCH more harm than good - but, for example, using a unknown random - 294,897 instead of 300,000 - cost factor and keeping it secret or adding a second secret salt buried deep in the code to the salt stored together with the username and hash will make it quite a bit harder for the attacker to perform an attack unless they got the information from an insider or were able to steal your code or binaries.
Using an in-code secret key (as opposed to the not-secret-by-necessity salt) is commonly referred to as a pepper. It improves security in the cases when an attacker has access to your database but not to your code or filesystem.
Figuring out the hashing scheme used for a given hash is frequently trivial. All an attacker needs to do is hijack his own hashed password and salt and then run combinations of common hashes with salting patterns until he gets a hit. This is going to be hundreds of combinations to test on the high end, and will generally yield results very easily.
> It does not really matter if you use ... a unique salt per user.
I agree with the other points that you make on this aspect but I do not quite understand this particular point (quoted above) can be true. If you use a strong unique salt for each user's password, then you are padding the length of actual password hashed and thereby effectively reducing the possibility of a successful dictionary attack to virtually zero. If this is so, then how could one mount a successful dictionary attack ?
It is common to store per user salts together with the hashes, often even as a single string formed by concatenating the salt and the hash. Therefore getting hold of the hashes usually means getting hold of the slats, too.
But the other case I mentioned - using the same salt buried deep in your code for all users (what is called a pepper as I learned recently) - will do what you describe until the attacker is able to figure out the pepper used by either stealing the code or brute forcing it.
Finally note that just using a pepper is no good idea and even when combined with a salt needs some careful thoughts. Just using a pepper will yield equal hashes for equal passwords while using a unique per user salt will avoided this. The other problem is that with a pepper you are reusing the same secret for each user. Therefore an attacker has thousands or even millions of samples and may be able to extract information if the scheme is not designed carefully. Combining password, salt and pepper must essentially avoid the same pitfalls as keyed hash functions when combining the key and the message. See for example the design principles behind HMAC [1].
[1] http://en.wikipedia.org/wiki/Hash-based_message_authenticati...
Back when Evernote was hacked, I got the idea of creating a draft of the kind of response I would prefer in a case like this.
I also intended to write a simple website script that could generate a statement. Things came up, and the gist has gathered dust for a while.
The gist is available here with some example cases listed that companies can learn from, and people are free to provide feedback or spin it off:
http://pygm.us/EwNHanBP
Post your most important feedback in its comments, so other companies reading the gist see it as well.
Companies definitely need to be prepared for full disclosure in the event of a security breach.
> How long was the salt? AFIK, MD5 hashes with an insufficiently long salt can be bruteforced with open sourced CUDA setups.
The length of the salt has little impact on security beyond 16 bits or so, where it's still feasible to generate rainbow tables for all salts.
If you're storing plain hashes, it doesn't really matter whether it's MD5, SHA-1 or SHA-256 - the work required for a brute-force attack is largely the same. The next step up would be using a key stretching algorithm like PBKDF2 or bcrypt.
Why do you want to know the hashing scheme? Isn't it better if nobody knows? :)
No