251–260 of 547 posts
Earlier quoted context omitted.
I'm even happier I don't have a LinkedIn account.
I've been tempted to delete mine several times recently. Looks like now is the moment.
Earlier quoted context omitted.
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.
Because the answer to your question is one Google search away. HN people are tired of explaining it every single time bcrypt comes up.
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…
While not entirely random, would a "date based" salt work as well? Say, the date that the entry was added? This would still negate rainbow tables as a specific user entry needs to be targeted.
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…
Often people say "Don't roll your own security" but the reality is that developers aren't trying to roll their own. They are trying to solve a problem, and if a quick google doesn't turn up a good library then they'll try and figure it out. Googling for password security implementations is likely to be fraught with horrible horrible advice. I guess what I'm saying is that it's not enough to say don't do it, instead t…
Earlier quoted context omitted.
Often people say "Don't roll your own security" but the reality is that developers aren't trying to roll their own. They are trying to solve a problem, and if a quick google doesn't turn up a good library then they'll try and figure it out. Googling for password security implementations is likely to be fraught with horrible horrible advice. I guess what I'm saying is that it's not enough to say don't do it, instead t…
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.
* Preventing password logging (many web frameworks log parameters)
* Secure password recovery
* New alternative attack vectors (eg. Facebook, Twitter auth)
* XSS and CSRF
Earlier quoted context omitted.
To be clear, MD5 (or SHA1 as these apparently are) is a problem. Passwords should be stored using a cryptographic hash function that is designed to hash passwords (read: be slow), not a generic cryptographic hash function (which are designed to be fast ). This is exactly the problem that bcrypt was created to solve (among others).
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.
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…
Hmm. My truncated password (for my now-deleted account) is not in the list of hashes -- so it's not just a uniq'd full DB. Also, the original forum thread where the file was first posted only managed to break around 600,491 passwords before it went offline ... so 3,521,180 broken passwords could mean that the original hacker has had access to some LinkedIn accounts for more than just a few minutes today.
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.)
It would make it a lot easier for LinkedIn to identify whose hashes were leaked because with a salt, all passwords would be unique. It would also make rainbow tables useless. But in this day and age, the bigger problem is how fast you can compute the hashes, salt or no. With GPUs you can calculate a few hundred million(depending on the hashing algorithm) per second, making the algorithm used the real vulnerability. B…
This is why you don't use really fast hashes for passwords and you iterate (key stretch). Bcrypt like you said.
Earlier quoted context omitted.
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.
Pbkdf2 is extremely good. Without deeper analysis (or a feature comparison) I'd be hesitant to say that bcrypt or scrypt are better.
From exactly where did you derive the idea that PBKDF2 is "extremely good"?
The reality is that all three of PBKDF2, bcrypt, and scrypt are just fine. But PBKDF2 and scrypt have drastically poorer library support than bcrypt; nobody should delay using a strong password hash so that they can optimize which one they use.
Earlier quoted context omitted.
Obligatory perl one-liner: perl -MDigest::SHA -le '$h = substr( Digest::SHA::sha1_hex($ARGV[0]) , 5 ); open F, " )' password (for people without shells)
Obligatory shell one-liner: grep `echo -n password | shasum | cut -c6-40` hacked.txt
$ 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