No, it doesn't work that way. You have to introduce memory in the equation. The whole point of bcrypt and scrypt is that they use a variable amount of memory (that cannot be optimized out) to calculate the final "hash". Often this takes the form of large lookup tables which cannot be inlined because they are accessed pseudorandomly, so you need to store them somehow.
What's the point, you will ask me? Well, look at a standard md5 hash. This requires basically no memory to implement, so you can grab a bunch of FPGA's and GPU's, make a cluster and hash a trillion passwords per second.
Now, look at your md5 variant with iterations. Ok, so now your FPGA's and GPU's have to work harder, but it's still pretty easy to implement - just add a for loop, essentially (and it's easy to change the amount of iterations). You might only be able to hash 20 million passwords a second with your cluster now, great.
Now consider bcrypt/scrypt, and have them set to require, say, 20MB of memory per hash (and be about as expensive as N rounds of md5). You attempt to implement it on your cluster, and.... BOOM! Not enough local memory to perform the hash, because now each hash iteration requires a non-negotiable 20MB of memory, and your GPU/custom chips certainly do not have that amount of memory available to them (for each hash they do in parallel, that is). Your cluster is now essentially useless - total hash rate: 0 hashes per second.
Basically, computational power can be parallelized cheaply and easily, but memory cannot. This is the cornerstone of bcrypt and scrypt. Obviously, they can still be broken by sheer brute force, and you could just use hardware with integrated memory units to circumvent the problem, but it's much harder and much, much more expensive to do so.
So overall, adding more iterations is fun and all, but it only scales linearly. Add twice as many iterations, hash half as much passwords a second. And eventually, the hash will take so long that the legitimate user will start to complain. But if you are clever and instead use the one weakness that current dedicated hardware has, you can completely wipe out a whole level of technology and force your opponents to adapt, which is much more efficient.
Of course, this is a rose-tinted vision of the real world, in practice people are still brute-forcing even those memory-hard hash algorithms, but it really is a significant improvement.
crypt
with the flagCRYPT_BLOWFISH
; it's been in there since PHP 4. $\endgroup$crypt
is in PHP 4, blowfish isn't, in the manual it says:5.3.0 PHP now contains its own implementation for the MD5 crypt, Standard DES, Extended DES and the Blowfish algorithms and will use that if the system lacks of support for one or more of the algorithms.
I have tested in PHP 5.2 there is no blowfish support. $\endgroup$