41–50 of 55 posts
I find it really incredible that this companies were so careless. Really. I know that security practices are rare to come by, but come on! LinkedIn, eHarmony and last.fm! These are some of the biggest websites.
I'd argue that security practices are not that hard to come by: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Earlier quoted context omitted.
But still a good point: Why limit your password length? My online banking is the worst offender that I know. Not only do they insist that the password is no longer than 8 characters, it HAS to be 8 characters. Madness!
I agree, banks having this flawed security is quite frightening! My bank used to have an 8 character password limit policy, but recently changed it (without announcing it), and I was able to use a 20+ character password. It's worth re-trying once in a while just to be sure.
Earlier quoted context omitted.
This page, when I read it a couple days ago, was pretty bad.
What reference would you recommend instead?
http://codahale.com/how-to-safely-store-a-password/
Let's be clear-eyed about this: we're talking about an OWASP page that says the "1-2-3" rules to do passwords well are "use SHA256", "pick a cryptographically random salt", and "iterate the hash".
Well, #1 is a suggestion that makes virtually no difference; your outcome won't be meaningfully worse if you use the (broken) MD5 algorithm than it will be if you use SHA-2.
And #2 is also a suggestion that makes virtually no difference; the (relatively unimportant) attack that "salts" blunt does not depend in any practical way on predicting salt values. Strong salt, weak salt, same deal: rainbow tables stop working, everything else still does.
Rule #3 is the only thing that matters on this page, but, of course, simply iterating your hash 64,000 times is an inferior solution to PBKDF2, bcrypt, and scrypt.
This page is a wiki, and I called it out on Twitter a day ago so the odds are some of this stuff has been "addressed"; but, I thought about taking a stab at fixing up the page and realized I'd be trying to incrementally improve that 1-2-3 advice. And, to the specific point of this thread: whatever better advice is there today, it wasn't there last week for LinkedIn or eHarmony to take advantage of.
"The API was developed 9 years ago, and appears not to have been updated since." Last.fm could have updated this, except it would have meant making all their users do something.
Why not use lazy rehashing? On login, the password is availible and so can be rehashed properly.
They send a token hashed with the password and they have to keep the original md5'd password on file in order to allow these clients to work.
Earlier quoted context omitted.
Even if we conservatively assume that you only need lowercase characters, and that you need one bit per password, that's still 26^16 bits = 4.6 ZB, about fifteen times the total capacity of every hard disk sold by Seagate in 2011 (330 EB).
They usually use less than one bit per password.
"The API was developed 9 years ago, and appears not to have been updated since." Last.fm could have updated this, except it would have meant making all their users do something.
Why not use lazy rehashing? On login, the password is availible and so can be rehashed properly.
BCRYPT(MD5(Password))
Earlier quoted context omitted.
Often people will store the password salt alongside their password hashes*, so if someone has the user table they would have the salts. --- At Authic.com we are investigating the practicalities of storing salts in a separate database from the password hashes.
Just use a hardcoded application salt (significantly large, >128 bytes is more than enough) in addition to your per-user salt (stored in the DB, or derived from a DB field). That way, an attacker would need both code access and DB access to crack the hashes, and if that happens you're basically screwed beyond redemption anyway.
And yes, you do have big problems if someone has access to your db AND code, but if you have done your job properly at least it will be very difficult/expensive/time consuming for the attackers to crack your hashes.
In the worst case scenario of someone dumping your entire database, you want there to be as much time as possible to contact your user base to let them know of the breach so that they can update their passwords before the crackers have finished the job.
Earlier quoted context omitted.
Doesn't that still leave the door open to database compromise? What are the practicalities of distributing the system among various technology stacks, minimizing the damage caused by a 0day or single engineered attack vector? Really thats just security by obscurity and the solution should be a robust system to begin with but I'm wondering about anticipating the human mistakes that render an otherwise secure system in…
Doesn't that still leave the door open to database compromise? Well, if you have it in the same DB table you are still at the mercy of database compromise. Better would be to store the salts in a separate table from your password hashes. Better yet, store it in a different database. And even better, store it on a different server. What are the practicalities of distributing the system among various technology stacks,…
Earlier quoted context omitted.
Why not use lazy rehashing? On login, the password is availible and so can be rehashed properly.
You can do better - if they're storing MD5s of the passwords, all they need to do is hash those again with another salt: BCRYPT(MD5(Password)) Running BCrypt or SCrypt over the current MD5 hashes is easy, and they can do it right now for every password. If someone (else) grabs the database in ten days time they get no MD5 hashes of passwords instead of half of the userbase.