121–130 of 219 posts
These are unsalted, md4 hashed, unicode strings.
They are fast and easy to crack if you ever do get your hands on them. The point is that many big companies don't do passwords right, so why expect Gawker to do so?
Edit: md4 is not a typo. They use md4 not md5... OK.
Earlier quoted context omitted.
Actually, it's essentially PBKDF1, but that's close enough for non-cryptographers.
Shit, you're right. (PBKDF2 generates arbitrary-length output, which is what you want from a key derivation function, but maybe not something you care about for a password hash). Here's a version that's much easier to read than the spec: https://github.com/emerose/pbkdf2-ruby/blob/master/lib/pbkdf... I should stop saying PBKDF2 and just go back to saying PBKDF.
Earlier quoted context omitted.
> That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt. I don't understand why you'd add extra content to the password unless you keep it secret. The whole point of a salt/nonce is to prevent attackers from attacking the digest, right? You need some per-user data, to defend against rainbow tables, and some per-site data, to protect weak passwords. My f…
> they impose a heavy performance penalty on authentication to avoid a relatively rare case You're authenticating over the internet . What is 1/10th of a second to authenticate the first time you want to log in relative to everything else? It's like complaining you have to put the key into your car before starting a five hundred mile road trip. Yes, it takes a few seconds. But worth it? Most definitely.
Maybe the correct thing to do is to make the key derivation executed on the client side, but then this would erode the experience of mobile phone users.
B-crypt and S-crypt are great libraries to use to solve this problem. However, the poor man's approach is as follows with HASH being your favorite hash function h = HASH.new() HASH.update(password) HASH.update(salt) for x in xrange(X): HASH.update(HASH.digest()) return HASH.digest() this approach "strengths" the hash by forcing you to calculate it over and over again. You should set X to be the number of rounds you w…
Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.
B-crypt and S-crypt are great libraries to use to solve this problem. However, the poor man's approach is as follows with HASH being your favorite hash function h = HASH.new() HASH.update(password) HASH.update(salt) for x in xrange(X): HASH.update(HASH.digest()) return HASH.digest() this approach "strengths" the hash by forcing you to calculate it over and over again. You should set X to be the number of rounds you w…
HASH.update(salt)
B-crypt and S-crypt are great libraries to use to solve this problem. However, the poor man's approach is as follows with HASH being your favorite hash function h = HASH.new() HASH.update(password) HASH.update(salt) for x in xrange(X): HASH.update(HASH.digest()) return HASH.digest() this approach "strengths" the hash by forcing you to calculate it over and over again. You should set X to be the number of rounds you w…
Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.
B-crypt and S-crypt are great libraries to use to solve this problem. However, the poor man's approach is as follows with HASH being your favorite hash function h = HASH.new() HASH.update(password) HASH.update(salt) for x in xrange(X): HASH.update(HASH.digest()) return HASH.digest() this approach "strengths" the hash by forcing you to calculate it over and over again. You should set X to be the number of rounds you w…
Why not also add HASH.update(salt) On each iteration as well? Then again, if things were this simple, someone would have already said "just do this", it would have been peer-reviewed and would have become widely used. Anyone know why this hasn't caught on yet in web frameworks like Django/Rails?
When working with cryptography, "why not also add" is really dangerous, because some times you get less secure systems after doing so. And other times you get no benefits from doing so.
Earlier quoted context omitted.
In a case like the Gawker incident, it isn't safe. If the source code to the password hashing algo is compromised (it was) then the salt becomes useless. In short, just use bcrypt.
No. No no no. The source code to the hashing algorithm means nothing . It is already open source! The reason that the salt is there is to prevent against rainbow tables. The salting did NOT become useless. If they had not salted passwords, then many many more passwords would have been broken because instead of having to brute force each and every one, you'd just look it up in a massively large hash table.
Earlier quoted context omitted.
> they impose a heavy performance penalty on authentication to avoid a relatively rare case You're authenticating over the internet . What is 1/10th of a second to authenticate the first time you want to log in relative to everything else? It's like complaining you have to put the key into your car before starting a five hundred mile road trip. Yes, it takes a few seconds. But worth it? Most definitely.
If you have 10 people logging in per second, you put a 1 second delay on future requests which is certainly noticeable. Maybe the correct thing to do is to make the key derivation executed on the client side, but then this would erode the experience of mobile phone users.
Earlier quoted context omitted.
> they impose a heavy performance penalty on authentication to avoid a relatively rare case You're authenticating over the internet . What is 1/10th of a second to authenticate the first time you want to log in relative to everything else? It's like complaining you have to put the key into your car before starting a five hundred mile road trip. Yes, it takes a few seconds. But worth it? Most definitely.
If you have 10 people logging in per second, you put a 1 second delay on future requests which is certainly noticeable. Maybe the correct thing to do is to make the key derivation executed on the client side, but then this would erode the experience of mobile phone users.
And if it really kills you to make it take a full second, then make it take 1/10th of a second: there, now your hashing is faster than the time it takes to dynamically generate a page.
People really need to learn that security doesn't come free, and some times you just need to bite down and say "You know what? I never plan on getting broken into, but just in case I do I'll take the tenth of a second extra computation in exchange for doing the right thing."