6.5 Million LinkedIn Password Hashes Leaked • Hacker News Board

Re: 6.5 Million LinkedIn Password Hashes Leaked

#241

Post by carbocation » Wed, Jun 06, 2012, 3:11 PM UTC

raverbashing wrote: post #122

carbocation wrote: post #50

Earlier quoted context omitted.

If a database of bcrypted passwords from LNKD had been leaked, we'd be having a totally different conversation right now. (Same, of course, with scrypt etc.)

Like you can't break bcrypt... The weakest link, either in bcrypt or MD5 is the password quality. Of course, in pure MD5 today you're a google search away and modern computers can eat salted MD5 for breakfast But the easiest passwords are going to be broken first

Am not a cryptographer by any means, so please correct me if I'm wrong:

If you use any reasonable cost for bcrypt, you're talking hundreds of milliseconds per attempt on a modern CPU. For each 6-character password (since you can't generate a rainbow table) at 100ms per pop, you're talking about something on the order of 2+ years per password divided by the number of CPUs. With something like 900 CPUs running continuously, you could expect to recover one 6-char every day if the passwords were randomly distributed in the 6-char alphanumeric space. So, pretty feasible, assuming a 100ms cost. Short passwords do hurt you; I agree.

Now for 8-char alphanumeric passwords, you'd have to run ~1 million CPUs continuously to expect to recover one per day at a 100ms-per-pop cost. This is more of a stretch, assuming you're trying to do this with, e.g., botnets. It seems that someone asking for help cracking a password list on a forum would probably not be able to assemble this much computing power.

Or 1 billion CPUs continuously to expect to recover one 10-char alphanumeric password per day.

Of course, the assumption of random alphanumerics is wrong, both because many people will use common passwords and because others will use non-alphanumeric character substitution.

At any rate, it seems to me that leaking non-salted SHA1 hashes is virtually the worst case disaster scenario, short of plaintext passwords.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#242

Post by akavel » Wed, Jun 06, 2012, 3:11 PM UTC

Aissen wrote: post #169

If you want to check if your password is in there: read -s a zgrep $(echo -n "$a" | sha1sum | cut -d' ' -f1 | \ sed -e 's/^...../00000/') combo_not.zip unset a

According to jgrahamc's investigation, this will probably check if your password is there and is cracked already. To check if the hash is there, although uncracked yet, you should probably remove the sed call from pipeline.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#243

Post by kmfrk » Wed, Jun 06, 2012, 3:12 PM UTC

mikeevans wrote: post #166

Terretta wrote: post #105

Earlier quoted context omitted.

What's causing you to have to retype passwords every few hours? If you're doing something that makes that normal procedure, consider using the browser inside 1Password for iOS.

Installing and updating apps, I'm guessing.

That, and the app sync prompts between iOS devices.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#244

Post by SoftwareMaven » Wed, Jun 06, 2012, 3:13 PM UTC

Smerity wrote: post #176

Jabbles wrote: post #138

Earlier quoted context omitted.

Surely just hashing the username|password would massively reduce the effectiveness of leaks like this? Sure, a hacker would know what the "salt" is, but since it now varies between users you would expend the same amount of effort breaking one person's login as you previously would spend breaking everyones (on average). (Not recommending it, just wondering if my reasoning is correct.)

I hear this commonly, so it is a good idea to clear it up. Usernames have lower entropy than a random salt and are predictable in many cases. People re-use usernames and some usernames are common. If your password system became common on the web, or if I knew the workings of your password system (i.e. open source / leaked codebase / Kerckhoffs's principle[1]), I could generate a rainbow table for either common or tar…

Bcrypt takes two lines of code to securely test passwords and two lines to created the hashed password, both of which come in the documentation.

There is every reason to use it and none not to.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#245

Post by Yoms » Wed, Jun 06, 2012, 3:14 PM UTC

riffraff wrote: post #232

jgrahamc wrote: post #170

Some observations on this file: 0. This is a file of SHA1 hashes of short strings (i.e. passwords). 1. There are 3,521,180 hashes that begin with 00000. I believe that these represent hashes that the hackers have already broken and they have marked them with 00000 to indicate that fact. Evidence for this is that the SHA1 hash of 'password' does not appear in the list, but the same hash with the first five characters…

fwiw, this could also be an elaborate hoax, given this facts. E.g. a list of simple password + combinations of the above simple password+"linkedin" variations.

My complex unique password is also on this list (full hash no 5 0's). So nope, not a hoax. Unbelievable/insulting they didn't even bother to salt.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#246

Post by tptacek » Wed, Jun 06, 2012, 3:14 PM UTC

carbocation wrote: post #241

raverbashing wrote: post #122

Earlier quoted context omitted.

Like you can't break bcrypt... The weakest link, either in bcrypt or MD5 is the password quality. Of course, in pure MD5 today you're a google search away and modern computers can eat salted MD5 for breakfast But the easiest passwords are going to be broken first

Am not a cryptographer by any means, so please correct me if I'm wrong: If you use any reasonable cost for bcrypt, you're talking hundreds of milliseconds per attempt on a modern CPU. For each 6-character password (since you can't generate a rainbow table) at 100ms per pop, you're talking about something on the order of 2+ years per password divided by the number of CPUs. With something like 900 CPUs running continuo…

You are not wrong at all.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#247

Post by Dexec » Wed, Jun 06, 2012, 3:15 PM UTC

mikeash wrote: post #211

Anderkent wrote: post #87

Earlier quoted context omitted.

Not finding 'password', 'foobar', '1234' suggests salted passwords.

'password' and 'foobar' are both in there. '1234' is not, but that's probably because of a minimum length requirement. Edit: '12345678' is in there, further bolstering the length requirement theory.

Correct.

From LinkedIn: "Passwords are case-sensitive and must be at least 6 characters."

Re: 6.5 Million LinkedIn Password Hashes Leaked

#248

Post by d503 » Wed, Jun 06, 2012, 3:15 PM UTC

dpritchett wrote: post #183

jgrahamc wrote: post #170

Some observations on this file: 0. This is a file of SHA1 hashes of short strings (i.e. passwords). 1. There are 3,521,180 hashes that begin with 00000. I believe that these represent hashes that the hackers have already broken and they have marked them with 00000 to indicate that fact. Evidence for this is that the SHA1 hash of 'password' does not appear in the list, but the same hash with the first five characters…

For the security novices amongst us: I had no idea how to do this so I figured out a quick python script to test it: >>> from hashlib import sha1 >>> def check_pass(plaintext, offset=5): hashed = sha1(plaintext).hexdigest() return (hashed, '0' * offset + hashed[offset:]) >>> check_pass("linkedin") ('7728240c80b6bfd450849405e8500d6d207783b6', '0000040c80b6bfd450849405e8500d6d207783b6') Edit: I'm pretty sure JtR refers…

If you're paranoid about shoulder-surfing you can use getpass to hide your password as you type it in.

    >>> import getpass
    >>> password = getpass.getpass('Password: ')

http://docs.python.org/library/getpass.html

Re: 6.5 Million LinkedIn Password Hashes Leaked

#249

Post by tptacek » Wed, Jun 06, 2012, 3:15 PM UTC

raverbashing wrote: post #41

chrisaycock wrote: post #25

Earlier quoted context omitted.

Better still, use scrypt. HN's very own @cperciva wrote it. http://www.tarsnap.com/scrypt.html It requires a lot more memory to brute-force it, thereby defeating any speed gains from parallelism.

THANK YOU "use bcrypt" has become an HN meme, with all the bad implications of it As if scrypt, pbkdf2 didn't exist. Or as if bcrypt has always existed and doesn't have any weakness

Please stop stirring up drama about this issue. While you are technically incorrect (PBKDF2-SHA1 is faster than and thus inferior to bcrypt), it's irrelevant: all three of [scrypt, bcrypt, PBKDF2] are just fine, and you can safely pick one at random.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#250

Post by Smerity » Wed, Jun 06, 2012, 3:16 PM UTC

asharp wrote: post #238

Smerity wrote: post #176

Earlier quoted context omitted.

I hear this commonly, so it is a good idea to clear it up. Usernames have lower entropy than a random salt and are predictable in many cases. People re-use usernames and some usernames are common. If your password system became common on the web, or if I knew the workings of your password system (i.e. open source / leaked codebase / Kerckhoffs's principle[1]), I could generate a rainbow table for either common or tar…

Having a password salted with the username fairly easily balloons out the complexity of building and searching a rainbow table by a factor of the number of usernames you want to be useful for. This factor is larger then you'd expect, given the sheer quantity and variety of usernames in various systems. For a targeted attack it really doesn't matter as the time complexity to produce the rainbow table is equivalent to…

The targeted attack does matter though, for the reason I pointed out above.

I can produce a rainbow table offline before I compromise the targeted system as I know the username of my target. This is not possible if the salt is random. This means I can crack a targeted user's password hash _instantly_ upon gaining access to the system.

With a random salt, you can only perform the brute force attack on that targeted user _after_ you've gained access to the system and likely alerted them to a compromise.

If the response time of the compromised system and team is a factor, this means using a username as a salt compromises your security greatly.

tl;dr Using a username for salting means a targeted attack against a single or small number of users would be damn near impossible to stop as the second they have the password hashes they also have the passwords.