101–110 of 144 posts
Earlier quoted context omitted.
How many bugfixes do you think a hash function needs? Just use jBCrypt.
If you try to use the spec'ed 32 rounds the code borks. I fixed it in my own version of jBCrypt.
Earlier quoted context omitted.
Every salt example I've run across until now used the same salt for every password in the database. Obviously I can disregard those examples! Thanks for bringing this up--the concept of salt makes a lot more sense to me now.
Ya, that's silly. A common and simple password setup is hash(username+password) or hash(private_account_attribute+password). Also, use bcrypt/scrypt/similar.
Earlier quoted context omitted.
> If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok". While I won't recommend people simply iterating a hash many times, I also won't slap people down for it anymore. In the grand scheme of things, there are a billion more likely routes of attack than someone breaking your 20000-rounds-of-SHA1 hashes.
Out of curiosity, what do you recommend people use?
The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…
As an example, find the md5 of a dictionary word and google it, its original value is bound to be in the first or second result. Now find the md5 of that word and a random string (aka a salt)... google and there shouldn't be any results. and even if there was due to a collision, that password wouldn't work, because it would be resalted prior to the comparison happening.
If you're storing passwords as MD5/SHA hashes, how difficult is it be to switch over to bcrypt? I've never had to do this, but I would imagine it would be somewhat trivial. With all of the password leaks that have happened over the past few years, I'd imagine a good amount of developers are aware that storing passwords as MD5/SHA hashes is somewhat risky, so I can't understand why big websites (LinkedIn) are still do…
Earlier quoted context omitted.
I think I answered my own question, but I'll ask anyway - why does memory intensiveness matter?
Processors get faster and faster, so we increase the work factor to compensate and keep it a time-hard problem. This has no real restriction on memory though, so the amount of memory only has to grow linear to the amount of time. Making it memory-hard makes it also memory hard.
That's a tautology, unless the hyphen means something different.
> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"
I mean this in the most polite and professional manner possible, please take five minutes and read http://codahale.com/how-to-safely-store-a-password/ . It will explain why "salts are useless for preventing dictionary attacks or brute force attacks." The entire article is excellent - and every colleague who I've ever pointed at it, has come away nodding their head and seeing the light. The key-takeway (but please, re…
> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"
MD5 is not fine. MD5 is very very fast[1] and as such it's possible to simply brute force password given relatively modest computing resources. The space of passwords just isn't that big. Use bcrypt or scrypt. Don't make up your own crypto. [1] Crypto benchmarks: http://www.cryptopp.com/benchmarks.html
> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"
MD5 is not fine. MD5 is very very fast[1] and as such it's possible to simply brute force password given relatively modest computing resources. The space of passwords just isn't that big. Use bcrypt or scrypt. Don't make up your own crypto. [1] Crypto benchmarks: http://www.cryptopp.com/benchmarks.html
> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"
MD5 is 'fine' for very long passwords. How many of your users have very long passwords? MD5 does nothing to make it hard to blaze through billions of possibilities.