6 ms·
I've just downloaded the database linked and it only contains the hashed passwords, not the account usernames / e-mail addresses. I wonder if someone has the a
by smiler 14y ago
I've just downloaded the database linked and it only contains the hashed passwords, not the account usernames / e-mail addresses.
I wonder if someone has the account details to match up otherwise you've no idea which password belongs to who, and you'd hope that LinkedIn would have lockout functionality.
- jere 14y agoAgreed. That seems rather useless. How would that happen anyway? The usernames stored in a different database/table from the hashes?
- joelhaasnoot 14y agoThey might need help cracking the hashes, keeping the usernames behind for their own exploits.
- nakkiel 14y agoOr they may use this as an advertisment for selling the actual dataset.
- hoov 14y agoLinkedIn allows you to sign in using any of your verified email addresses, so it seems likely that the usernames are at least stored in a different table.
- snorkel 14y ago... but still, a head wag at LinkedIn for using weak hashing, which I'm guessing means MD5.
- DaveChild 14y agoMD5 isn't the issue - it's the lack of salting. Without a salt, almost any hash can be cracked with a rainbow table. With a salt, you'd need to know the salt for each hash, and then generate a new rainbow table, in order to recover the original password.
- eropple 14y agoThis isn't really the issue. The real issue is that MD5 (though these hashes are SHA1, which has the same problem) are too easily computed; they are practically byte-forceable. I don't need a rainbow table to compute hashes when I can slam out millions in short order using a GPU. You have a good point about needing to know the salt, but getting the salt is generally easy because it's usually stored in the same place as the hashes (and this practice is fine, because hiding the salts doesn't improve security significantly on its own). This is a major reason to use bcrypt.
- romaniv 14y agoLet's forget about bcrypt for a second. What prevents developers from adding a large DB-wide salt (in addition to normal salt) to every password? Wouldn't that prevent bruteforce attacks regardless of the hashing algorithm?
- brown9-2 14y agoIs there a significant time difference in computing the SHA1 hash of 40 bytes versus say, 128 bytes?
- romaniv 14y ago128 bytes is not "large". I was thinking more along the lines of megabyte+. There is no question that it will slow down hash computations, because you would need to process more data. The question is, can you efficiently parallellize this in a commodity hardware (GPUs)?
- tptacek 14y agoRandom nonces have very little to do with what makes SHA1 insecure and bcrypt secure. Developers have a very weird and totally misplaced faith in the ability of random "salts" to secure passwords.
- romaniv 14y ago
- madsr 14y agoKeep in mind that whoever leaked the hashes is probably keeping the usernames / emails for themselves. The forum in question doesn't allow posting of user-identifiable information according to the forum guidelines. The leaked hashes seems to be SHA-1. I've also confirmed that the hash of my own (semi-complex) LinkedIn password is in the list. Accidentally this is the same password as I had for HN and that I've now changed (phew! THAT'd been bad! :-)
- mjschultz 14y agoDoesn'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.
- madsr 14y agoYes. The hash I calculated was without a salt (the same way you generate a hash on sites like http://darrenfauth.com/generators/sha1 http://darrenfauth.com/generators/sha1)
- deleted 14y ago[deleted]
- joesmoe4297 14y agoYou can get reflected XSS in that field. Paste "<script>alert('XSS')</script>" in the "Value to sha1" input box. Darren, you should check out output encoding.
- 16s 14y agoWith these sorts of simple hashes, you don't need rainbow tables when you have a few GPUs and OCLHashcat.
- veemjeem 14y agoIt would still take a moderate amount of time for a single password if it's long and complex -- you're essentially generating the rainbow table. You might as well just download a sha1 rainbow table and just perform a O(1) lookup. You could reverse all the 6.5M password hashes in mere seconds.
- rbanffy 14y agoYou can use it for checking whether your password was leaked. You don't need usernames for that.
- TomGullen 14y agoAre the hashed passwords not salted?
- ithkuil 14y agoYou can perform this check even if they were salted. Otherwise how could linkedin check if you correctly entered your password? The salt is contained in cleartext as part of the hashed password, so that you can repeat the hashing the secret and match the two hashes. The salt improves the security because: 1. even if two users use the same password, you cannot tell that by simply comparing the hashes 2. makes brute force checks much slower because you have to recompute the hash for every hashed password entry rather than once for every dictionary entry 3. Prevents building rainbow tables (probably other reasons, I'm not a crypto expert)
- leftnode 14y agoThe salt may have been stored in a separate database table and not distributed with this list (if they were salted, which apparently they aren't).
- thaumaturgy 14y agoNo. I was just confirming that myself when I saw madsr's comment: http://news.ycombinator.com/item?id=4073454 http://news.ycombinator.com/item?id=4073454
- kevindication 14y agoLinkedIn could easily match each hash to a user. Then they should lock each of those accounts and force them to change their password.
- carbocation 14y agoWhich should be done, but which doesn't help those users where it matters most; the real value of this database is that some people (~everyone) reuses passwords across sites.
- kevindication 14y agoAnd send them a note too, sure. They've got their e-mail addresses as well so a note of apology and warning is certainly in order.
- mibbitier 14y agoFrom the looks of it, the data dump may be all accounts - since there seems to be no salt, and many people use same passwords...
- NatW 14y agoTo get a sense of it, I downloaded it from a link here. Below is the structure of the first few lines. Caveat: it's garbage/useless data below -- I intentionally changed around the actual numbers to give a sense of the structure, only: 000000a94d47b9cb82ca8a3b492a51263b40a66e 000000a98a624314892af97c6f1a0635472eae38 000000a9ba60e7f13fcac444a5a791af7807a3a3 000000a97ea34e74a97a6d1ce08ebc68d3e9aab2 000000a9b4b2a3497aaa51e212ac9efdb00aaf4e
- Anderkent 14y agoThe pattern 000000a9 is just in presentation - I counted the occurrences of different bytes in that position (also misled by the apparent pattern, where many lines in a row would have the same 4th byte), and each possible value is present more or less equally often. It seems like it's just sha1. EDIT: however, 3.5 million hashes start with 5 zeroes, which is way too many for just coincidence. Possibly they used multiple hash functions?
- ricardobeat 14y agoIt appears that the publisher just zeroed out the first 4 digits in nearly all the hashes. The rest of the string still matches known hashes.
- ominous 14y agoFound this on reddit: http://www.reddit.com/r/netsec/comments/unubl/if_it_turns_out_that_linkedin_passwords_have/c4wz7pg http://www.reddit.com/r/netsec/comments/unubl/if_it_turns_ou... My password it not in there, but some people have already reported finding theirs.