Live data from Hacker News

6.5 Million LinkedIn Password Hashes Leaked

translate.google.com

281–290 of 547 posts

Re: 6.5 Million LinkedIn Password Hashes Leaked

#281
post #266

Earlier quoted context omitted.

The perl one liner was funny, the shell one liner was light hearted, but your node solution is just pure fanboyism and quite frankly not in line with the spirit of the two previous posts.

And.. the node.js solution doesn't do what either the Perl or shell one liners do. It doesn't tell you whether the password was found in the file. All it does is print out a SHA1 hash of a string.

That's a trivial modification:

    $ echo linkedin | xargs node -e "var x = require('crypto').createHash('sha1').update(process.argv[1]).digest('hex'); console.log(x.substring(5));" | xargs -I {} grep {} hashes.txt
I'm surprised at the backlash to what I thought was fun code golfing. No one called me names after I posted a simple Python solution that didn't check the file. For what it's worth I've changed my LI password and I haven't bothered downloading the actual hash file.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#282

Earlier quoted context omitted.

Nothing, really. However, I trust the LastPass guys to keep their shit secure as much as I trust myself to keep my own system secure. After all, if my own system is compromised, I just get a lot of hassle. If LastPass ever gets hacked and leaks their passwords, they lose their business overnight. That's pretty good motivation for them to keep on top of their stuff. I used to use 1Passwd, which stored the passwords in…

The big difference between "hosted service" and "encrypted file in the cloud" is that the hosted service has, by definition, to store the key next to the lock to be practical. The key for your encrypted file stays in your head (and/or in your wallet), so even a full-on total breach of Dropbox/iCloud, your key is safe, and 8 million rounds of 265-bit AES and a good password (my current KeePass settings) is still unbre…

Why can't the hosted service use an "encrypted file in the cloud" as its implementation? As long as it requires client-side code to do the decryption, the key stays in your head alone.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#283
post #238

Earlier quoted context omitted.

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 us…

Sure you can, assuming:

1) You know the hash function beforehand 2) You know that they are salting in exactly this way 3) You know how they are doing their salting (HMAC vs., vs.) 4) You have enough time to create this new rainbow table 5) You have only just enough access to the system to dump the hashes (ie. the easier routes are blocked off from you)

That would in fact, with some probability (based upon the complexity of your rainbow table and the complexity of the users password), give you the passwords for a particular set of users.

I did say that it was more secure then it seems, not that it was perfectly secure :)

Re: 6.5 Million LinkedIn Password Hashes Leaked

#284

Earlier quoted context omitted.

Correct! 527688fa9f32bb8dab32d30807ca5c57a0b203b8 is not present 000008fa9f32bb8dab32d30807ca5c57a0b203b8 is present

Here's some they didn't find, from /usr/dict/words: Paraná, Zürich, attaché. Not sure of the encoding, but I'd guess UTF-8.

My not so strong password is not in the list, spacex12, and Ive checked if it was already cracked by the prefix of 00000, nope.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#286

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…

Another data point:

I changed my linkedin password about three weeks ago. The old one is in the list (already 00000-ed), the new one isn't.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#287
post #48

Earlier quoted context omitted.

Doesn't this imply that LinkedIn doesn't salt the password prior to storing it. So then a good chunk of those passwords will be in a rainbow table.

Yes. The hash I calculated was without a salt (the same way you generate a hash on sites like http://darrenfauth.com/generators/sha1 )

[deleted]

Re: 6.5 Million LinkedIn Password Hashes Leaked

#288
post #173

Earlier quoted context omitted.

This is why I use 1password and not LastPass - the encrypted password file is stored locally - optionally in Dropbox, which is what enables moble and remote (http online through Dropbox) to work. Works excellently!

LastPass encrypts your passwords using your master password as (at least part of) the key. This means that they do decryption of passwords client-side as well. The entire password file is not stored locally but they had an intrusion of some sort a number of months back which demonstrated that they have a pretty good system set up along with quite a bit of monitoring. Truecrypt in dropbox is obviously a good choice if…

The LastPass UX is anything but simple

Re: 6.5 Million LinkedIn Password Hashes Leaked

#289
post #48

Earlier quoted context omitted.

Doesn't this imply that LinkedIn doesn't salt the password prior to storing it. So then a good chunk of those passwords will be in a rainbow table.

Yes. The hash I calculated was without a salt (the same way you generate a hash on sites like http://darrenfauth.com/generators/sha1 )

You can get reflected XSS in that field. Paste "alert('XSS')" in the "Value to sha1" input box.

Darren, you should check out output encoding.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#290
post #242
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.

Oh. You're right, I missed that. New command line:

    read -s a; zgrep --color -E $(hash=$(echo -n "$a" | sha1sum | cut -d' ' -f1); echo -n "$hash|$(echo $hash | sed -e 's/^...../00000/')" ) combo_not.zip ; unset a
Post reply on HN