When seeing the title, I was expecting an article about CMAC or HMAC or even PBKDF2-like function but it's the "old" bcrypt.
You say that as if it's a bad thing.
EDIT: Oh, you mean it was similar to other submissions. Fair enough.
How To Safely Store A Password
91–100 of 219 posts
Re: How To Safely Store A Password
#92Earlier quoted context omitted.
Ah, alright. I was thinking there was some kind of length-extension weakness (which doesn't apply here, which is why I was confused) or some other attack in the cryptographic sense. Thanks.
SHA1(salt || password) does have a length-extension property; you can easily compute SHA1(salt || password || junk || arbitrary-data) for any given hash. That's not very useful for password hashes, but is devastating for the kinds of SHA1-based authentication schemes that people who write their own password hashes seem to come up with.
Yeah, by "doesn't apply" I meant "that's not very useful for password hashes".
Re: How To Safely Store A Password
#93Earlier quoted context omitted.
I am looking right now at Schneier's reference implementation of the Blowfish key setup function, and there is nothing in it that would not be straightforward to parallelize across a CUDA warp (read: no conditional branches). Is it your assertion that getting from here to a working bcrypt cracker would be sufficiently difficult as to constitute a significant "contribution to cryptography literature"?
You win this time, Franke. This time.
Are you earnestly conceding, or are you just bogged down in enough other arguments that you don't want to deal with this one?
Re: How To Safely Store A Password
#94When seeing the title, I was expecting an article about CMAC or HMAC or even PBKDF2-like function but it's the "old" bcrypt.
You say that as if it's a bad thing. EDIT: Oh, you mean it was similar to other submissions. Fair enough.
Not really. Just it was already mentioned sometimes ago about the fixed cost function in bcrypt:
Re: How To Safely Store A Password
#95Earlier quoted context omitted.
Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc). There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems.
If you lose code execution on your server to an attacker, you're done. 100% fucked. Everything in your environment needs to get stripped down and rebuilt from trusted sources. Do not be one of those people who rationalizes "oh, I just lost uid=4294967294". Gawker lost root. So will you.
And if you lose root, the disk must be reimaged. Rootkits are too advanced these days to ever make the assumption that you have removed them.
Re: How To Safely Store A Password
#96B-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.
Re: How To Safely Store A Password
#97If you have a 5-year old database using a given bcrypt work factor, how difficult is it to transition to a new, higher work factor?
I'm no expert, but I think you could just convert a database via function composition:
new_hash = (bcrypt new_work_factor) . old_hash -- new hashing function
new_hashed_passwords = map bcrypt old_hashed_passwords -- convert the old hashed passwords to new
Re: How To Safely Store A Password
#98Earlier quoted context omitted.
No. Use Bcrypt. Always. Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast. So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basic…
The question is not whether BCrypt is backed by Blowfish, the question is whether BCrypt uses Blowfish in a way which is cryptographically sound. If it does not, then an attacker may not need to use brute force. Assuming the author has read more of Mr. Schneier's book than the quoted preamble, he should know this -- Schneier discusses this at length in both editions of Applied Cryptography . Again, an example of this…
You're speculating about the existence of a flaw which is there no evidence to believe could exist. Just because some crypto constructions are not as sound as naive theory suggests does not mean all constructions are flawed, or even capable of being flawed.
bcrypt is not an encryption algorithm. It doesn't "protect" your users' data, so there's no reason to trust or not trust it with their data.
Re: How To Safely Store A Password
#99Earlier quoted context omitted.
I'm curious what the attack is that makes that easier to crack than the Gawker way. (I'm sure you're right, I just didn't know that it would be easier.)
SHA1 might (I think it is, but I'm not sure) be faster than DES; among other differences, DES crypt(3) has to run the DES key schedule before producing a hash. Data slips through SHA1 like a greased seal.
Looks like you're right.. these benchmarks show SHA1 about 5x faster than DES: http://www.cryptopp.com/benchmarks.html