Live data from Hacker News

6.5 Million LinkedIn Password Hashes Leaked

translate.google.com

371–380 of 547 posts

Re: 6.5 Million LinkedIn Password Hashes Leaked

#371

Earlier quoted context omitted.

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…

Obligatory perl one-liner: perl -MDigest::SHA -le '$h = substr( Digest::SHA::sha1_hex($ARGV[0]) , 5 ); open F, " )' password (for people without shells)

You might compare many words at once (say from a popular password list such as rockyou) like this:

while read line; do echo -n $line | sha1sum | cut -c6-40 | awk '{print "00000" $0}'; done I haven't tested that, but I think it'll work.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#373
post #158

Earlier quoted context omitted.

Given that these hashes are not salted, running a 'uniq' on the list of all users' password hashes would probably already cut it by half, if not more. Then you eliminate all the easy ones from wordlists, and post the remains on the internet for people with excess computing power to bruteforce.

They are already unique and sorted. sort -u combo_not.txt | wc -l 6458020 wc -l combo_not.txt 6458020

I assume the first line you meant to pipe it through uniq afer the sort? Otherwise the only thing you've demonstrated is that sorting a file doesn't change its line count. :)

Re: 6.5 Million LinkedIn Password Hashes Leaked

#374

Earlier quoted context omitted.

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

We're speaking about a very specific attack here: bruteforce. And I'm speaking about a very specific type of "salt" (which could probably be called something else, since it's not the same as normal unique-per-password salt): large, database-wide string of random bytes. If every password is padded with such a string before hashing, computing the hash would be slower. Obviously, it would be slower because you would hav…

[deleted]

Re: 6.5 Million LinkedIn Password Hashes Leaked

#375

Earlier quoted context omitted.

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…

Obligatory perl one-liner: perl -MDigest::SHA -le '$h = substr( Digest::SHA::sha1_hex($ARGV[0]) , 5 ); open F, " )' password (for people without shells)

By sheer coincidence I had a chance to use Perl again today for a job interview.

I now have a good appreciation of why it's considered a "Write once, read never" language. :)

Re: 6.5 Million LinkedIn Password Hashes Leaked

#376

Earlier quoted context omitted.

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

We're speaking about a very specific attack here: bruteforce. And I'm speaking about a very specific type of "salt" (which could probably be called something else, since it's not the same as normal unique-per-password salt): large, database-wide string of random bytes. If every password is padded with such a string before hashing, computing the hash would be slower. Obviously, it would be slower because you would hav…

[deleted]

Re: 6.5 Million LinkedIn Password Hashes Leaked

#377

Earlier quoted context omitted.

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

We're speaking about a very specific attack here: bruteforce. And I'm speaking about a very specific type of "salt" (which could probably be called something else, since it's not the same as normal unique-per-password salt): large, database-wide string of random bytes. If every password is padded with such a string before hashing, computing the hash would be slower. Obviously, it would be slower because you would hav…

None of this makes much sense to me, sorry. Brute-force password cracking has worked on salted passwords since Alec Muffett released Crack in the early '90s. The amount of extra computational power required to hash a password and a salt is negligible.

The only thing "salts" do is prevent rainbow table precomputation, but it's just a quirk of the late '90s and early '00s that "rainbow tables" ever became a mainstream attack method: one bad Microsoft password hash and a series of bad web applications. Long before the MD4 LANMAN hash was ever released, people were breaking salted Unix passwords with off-the-shelf tools, on much, much slower computers than we have now.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#378

Earlier quoted context omitted.

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

We're speaking about a very specific attack here: bruteforce. And I'm speaking about a very specific type of "salt" (which could probably be called something else, since it's not the same as normal unique-per-password salt): large, database-wide string of random bytes. If every password is padded with such a string before hashing, computing the hash would be slower. Obviously, it would be slower because you would hav…

How much slower would you estimate it being?

Re: 6.5 Million LinkedIn Password Hashes Leaked

#379
post #99
post #12

Earlier quoted context omitted.

To expand on that, to store passwords don't just use salt+sha1, or try to do your own nested sha1, just use bcrypt: http://en.wikipedia.org/wiki/Bcrypt

I wonder, why do people saying "just use bcrypt" never, ever bother to elaborate on what benefits it has, and which of them are relevant to the subject of the conversation? Believing in some function without understanding implications of its use does very little for real security.

Bcrypt does not require your understanding. The most important thing is that you use a strong password hashing method -- of which bcrypt is the best-known, and an excellent choice. For a basic level of understanding, here's a slightly exasperated blog post that a lot of people link to:

http://codahale.com/how-to-safely-store-a-password/

Re: 6.5 Million LinkedIn Password Hashes Leaked

#380

Earlier quoted context omitted.

Here's node.js: $ echo linkedin | xargs node -e "var x = require('crypto').createHash('sha1').update(process.argv[1]).digest('hex'); console.log([x, '00000' + x.substring(5)]);" 7728240c80b6bfd450849405e8500d6d207783b6 0000040c80b6bfd450849405e8500d6d207783b6

Or you could just feed "sha1 " to the duckduckgo.com search box and it will give the result.

Challenge accepted (although this is pretty crude)

curl -s -d q="sha1 password" http://duckduckgo.com | w3m -T text/html | grep '\w\+\{32\}'

Post reply on HN