Password leaks bigger than first thought

http://www.h-online.com/security/news/item/Password-leaks-bigger-than-first-thought-1614516.html

by bond • 14 years ago

33 52 14 years ago

TrevorJ• 14 years ago

Does the number of passwords in the hashed list matter in terms of how easy or hard they will be to crack? Does this have implications for a rainbow table-type attack?

lucian1900• 14 years ago

I guess the more you have, the more information you have about the salt used. I'm not sure it'd be useful though.

And many of these hashes aren't salted anyway.

pixelcort• 14 years ago

The real question is, if a site used a salt, was it a per-user salt or a global salt?

zizee10• 14 years ago

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.

zizee10• 14 years ago

It would increase the likelihood of more common passwords being present in the list giving the attackers insight into what hashing technique was being used to store the passwords.

But the difference between 10,000 hashes and 10,000,000 would not make it easier to crack.

lomegor2• 14 years ago

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.

waterlesscloud• 14 years ago

I would be very surprised if this sort of problem is not quite widespread among companies with giant userbases.

We'll see more of these, and bigger ones.

16s2• 14 years ago

Microsoft Active Directory servers store passwords as plain MD4 hashes. http://16s.us/ms_ad_hashes/

These servers are used by governments and large organizations all over the world.

DanielRibeiro• 14 years ago

I'd argue that security practices are not that hard to come by:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

lomegor2• 14 years ago

I meant that are hard to see implemented on websites, not hard to find. Sorry

tptacek2• 14 years ago

This page, when I read it a couple days ago, was pretty bad.

MehdiEG• 14 years ago

"And one amusing detail – although eHarmony implores its users to use strong passwords including both upper and lower case letters, it saves the passwords in all upper case"

This is truly beautiful - made my day :)

waffle_ss2• 14 years ago

Unsurprising that >95% of the password hashes have been broken. I remember being annoyed when I signed up for LinkedIn (just checked my tweet history - it was 2010/06/10) because they were only allowing 16 characters in the password field.

EDIT: Whoops, guess I should have done some napkin math before claiming that there are rainbow tables that cover that area. /me slaps wrist

Jabbles• 14 years ago

26^16 ~ 4e22, so no such rainbow tables exist.

rpearl2• 14 years ago

I mean... there are surely not rainbow tables that span all 62^16 16-character passwords consisting of alphanumerics only: that is 646,081,519 zettabytes of hashes (62^16 * 128 bits).

There are clearly rainbow tables which span a more useful dictionary of passwords, though--and certainly all the most common passwords.

duskwuff• 14 years ago

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

waffle_ss2• 14 years ago

You are absolutely correct; I should have actually done the 5-second calculation before writing that instead of relying on my flawed memory.

Looks like the publicly available rainbow tables go out to 7 characters with special chars included, which comes out to a much more reasonable 3.2 TB (using 62 chars).

zizee10• 14 years ago

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!

jacktoole1• 14 years ago

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.

chrischen3• 14 years ago

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

terangdom2• 14 years ago

Why not use lazy rehashing? On login, the password is availible and so can be rehashed properly.

chrischen3• 14 years ago

Mainly because many Last.fm scrobbling clients relied on the legacy API that uses a person's password as a private key to authorize requests.

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.

repsilat• 14 years ago

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.

ams6110• 14 years ago

Last month Last.fm admitted to having received several reports of spamming involving user data.

Over the last 6--9 months I have definitely noticed an uptick in the random "connection" requests I get on LinkedIn. I don't know if this is because their userbase has grown and more people are just shotgunning connection requests, or if these represent first steps at an attempted social engineering attack via hacked accounts on which I appear in the "people you might know."

So far none of these have been from people I actually know even remotely, so I'm guessing it's just simple spam (and I report it as such).

zizee10• 14 years ago

What do people think about outsourcing your authentication to someone else?

Full Disclosure: I'm currently working on a brandable authentication host (http://www.authic.com) that will outsource the pain of storing your password hashes securly and provide your web app with slick a user account UX.

latchkey3• 14 years ago

I'm offering my users Browserid and/or Facebook in order to login. Works great and passwords are definitely something I'd rather not deal with. Also saves me from having to implement all sorts of stuff like forgot password, forgot username, etc.

zizee10• 14 years ago

Do you also offer your own login forms?

cheald2• 14 years ago

We all do it daily with Facebook et al delegated authentications.

dredmorbius2• 14 years ago

My own personal attitude is that I'd prefer having independent, unlinked accounts among various service providers, for which I use long, randomly generated passwords.

My risk from any given service is relatively low. My passwords are strong enough (trillions to quintillions of years brute-forcing time per the online calculator's I've checked -- with similarly constructed passwords, not my actual ones, natch) that risk of bruting a hashed key is low, and I don't re-use passwords. For services that store passwords in cleartext (still fairly common practice on mailing lists), no big loss either.

Havoc• 14 years ago

Unsalted hashes. Wow. What a bunch of amateurs.

Also, 10 internet points says at least one other major website will fall too within 2 weeks. Someone has found a new exploit & is trying various sites & collecting hashes.

getsat• 14 years ago

It doesn't really matter if you're salting or not when you use really fast general purpose hashing functions. Consumer video cards can calculate half a billion SHA/MD hashes per second nowadays. You're talking minutes vs seconds. Unacceptable.

Password leaks bigger than first thought

Related Stories