Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

6.5 Million LinkedIn Password Hashes Leaked

translate.google.com

Post reply on HN
Print view View original

261–270 of 547 posts

Re: 6.5 Million LinkedIn Password Hashes Leaked

#261

Post by tptacek »

Glowbox wrote: post #45
tocomment wrote: post #30

This makes me wonder. I've been relying on Django's built in user authentication lately. Does anyone know if that's pretty safe? Is it doing the right thing for hashing passwords?

Disclaimer: I am not a cryptographic expert. https://docs.djangoproject.com/en/dev/topics/auth/ Django by default uses the PBKDF2 algorithm, which is better than nothing/md5/no salt sha1. I'd use bcrypt or scrypt by default, better be safe than sorry.

Django has chosen a fine default and for the next several years it's probably unnecessary to second-guess it. Over time, GPU and (more importantly) FPGA-assisted hash cracking may or may not become more common, at which point you'd want to transition to something like scrypt.

You could literally flip a coin to decide between bcrypt and PBKDF2 and it wouldn't matter which side came up.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#262

Post by tptacek »

taybenlor wrote: post #255
Smerity wrote: post #226

Earlier quoted context omitted.

I think we've reached a point with bcrypt that a good secure password system is within reach and comes with sane defaults and ease of use as features for most programming languages. If it's just an issue of getting the word out there, then I'm hopeful things can improve.

You need more than just bcrypt. You've hinted at other things, but a few random things popping in to my mind: * Preventing password logging (many web frameworks log parameters) * Secure password recovery * New alternative attack vectors (eg. Facebook, Twitter auth) * XSS and CSRF There are so, so many simple to make security errors, and worse - many of them are inter-related so that forgetting one will make another v…

A strong password hash doesn't gate on any of those things, so, while you do indeed need to pay attention to them, you don't need to pay attention to them before you deploy a strong password hash.

You should deploy a strong password hash immediately.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#264

Post by jere »

jlgreco wrote: post #91
jere wrote: post #84

Earlier quoted context omitted.

I think people are missing the point that SHA2 is light years ahead of MD5. MD5 has had known security flaws for years . >Do not use the MD5 algorithm Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. http://www.kb.cert.org/vuls/id/836068 This is from over 3 years ago.

The primary problem with using either as a password hash is their speed.

I agree, but my point is that the "use bcrypt" drum has only been beating for a couple years to my knowledge: http://codahale.com/how-to-safely-store-a-password/

Wind the clock back 3-5 years and it's still stupid to use MD5. I could kind of understand some old code laying around that was less secure.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#265

Post by barik »

madmaze wrote: post #204
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…

I disagree with #5, I had a few of my coworkers check their sha1 against the DB and most of them were not in the dump. I also checked for truncated hashed, none of which were found. I have the feeling this is a subset of the full database

I don't really see a purpose in hiding my password. So, as a counterpoint, my password is in the list. This is my LinkedIn password:

AxEWS9rg5V

This is the sha1:

caf28fcc9c3e4d88b830b8e5cc52c5b65d3db5f4

It is found in Line 3612910 of combo_not.txt. I believe the file is authentic.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#266

Post by zxcvb »

dpritchett wrote: post #260
jgrahamc wrote: post #224

Earlier quoted context omitted.

Obligatory shell one-liner: grep `echo -n password | shasum | cut -c6-40` hacked.txt

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

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.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#268

Post by jere »

veemjeem wrote: post #141
jere wrote: post #84

Earlier quoted context omitted.

I think people are missing the point that SHA2 is light years ahead of MD5. MD5 has had known security flaws for years . >Do not use the MD5 algorithm Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. http://www.kb.cert.org/vuls/id/836068 This is from over 3 years ago.

Still, it doesn't matter. As long as one can generate a rainbow table for the hash function, then password lookups will be a O(1) operation. The rainbow table for md5 is moderately small, sha1 is bigger, and I'm sure sha2 is even bigger than the sha1 table.

I'm discussing SHA-2 vs MD5. I wouldn't use any hash function without a salt.... which makes the discussion of rainbow tables irrelevant.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#269

Post by romaniv »

brown9-2 wrote: post #156
romaniv wrote: post #125

Earlier quoted context omitted.

Let'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?

Is there a significant time difference in computing the SHA1 hash of 40 bytes versus say, 128 bytes?

128 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)?

Re: 6.5 Million LinkedIn Password Hashes Leaked

#270

Post by darkarmani »

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

What weakness does bcrypt have?
Post reply on HN