How is bcrypt more future proof than increasing th

问题:

I've been researching bcrypt hashing, and of course one of the large benefits of the scheme its "adaptiveness". However, how is it anymore adaptive than simply increasing the amount of iterations you make over a SHA-1 hash? Say, instead of SHA-1 hashing a value 1000 times, you increase it to 10,000 iterations. Isn't this achieving the same goal? What makes bcrypt more adaptive?

回答1:

Making many iterations with a hash function has a few subtleties, because there must be some kind of "salting" involved, and because existing hash functions are not as "random" as what could be hoped for; so care must be taken, in which case you end up with PBKDF2. PBKDF2 was designed for key derivation, which is not exactly the same than password hashing, but it turned out to be quite good at it too.

bcrypt has a (slight) advantage over PBKDF2-with-SHA-1 in that bcrypt is derived from the Blowfish block cipher. The point of having many iterations is to make the password processing slow, and, in particular, slow for the attacker. We tolerate that the function is made slow for the normal, honest systems, because it thwarts extensive password guessing. But an attacker may use hardware which the normal system does not use, e.g. a programmable GPU, which gives quite a boost to computations which fit well on that kind of hardware. Blowfish and bcrypt use RAM-based lookup tables (tables which are modified during the processing); such tables are easy to handle for a general purpose CPU, but quite cumbersome on a GPU; thus, bcrypt somewhat hinders processing enhancement by the attacker with GPU. That's a bonus which makes bcrypt a bit more desirable for a password storage than PBKDF2.

回答2:

An alternative to both is scrypt. Unlike bcrypt, it doesn't make use of the somewhat unusual blowfish cipher, instead using any standard hash function, and it's specifically designed to be difficult to implement on dedicated hardware, by being both memory- and time-inefficient.

回答3:

Your alternative is a bit underspecified. You didn't say how you combine password and salt into your hashing scheme. Doing this in the wrong way might lead to vulnerabilities. The advantage of bcrypt(and other standard KDFs) is that this is well specified.

If you look at PBKDF2 in the common HMAC-SHA1 mode it's very simililar to what you suggest.

回答4:

That's essentially it. You can iterate any hash function. Some hash functions are better than other, so choose carefully.

MD5 for example is considered broken these days, and belongs to a category of hash functions which suffer from certain prefix-based attacks and birthday attacks.

bcrypt is a good rule-of-thumb because it gets a few things right (like salt) that you would have to explicitly implement if you used another function.

回答5:

As noted in another answer the mechanism of iterating a hash function is very important, because it can unexpectedly weaken the algorithm or still fail to prevent some time-memory tradeoff attacks.

This is why PBKDF2 is your friend. It's detailed in RFC 2898. PBKDF2 is also future-proof because it doesn't depend on a specific hash algorithm. For example, can swap out MD5 for SHA3 when SHA3 is finalized by NIST.

Also, a slight catch on future-proofness. Bcrypt will work as long as the passphrase you're protecting is "between 8 and 56 characters." An important catch to keep in mind should your future ever require longer passphrases for some reason.

回答6:

I believe the "adaptiveness" has nothing to do with the actual encryption but instead that bcrypt is an adaptive hash: over time it can be made slower and slower so it remains resistant to specific brute-force search attacks against the hash and the salt.

(Partly quoted from http://en.wikipedia.org/wiki/Bcrypt)