When trying to hash passwords, the attacker can always use the same kind of hardware as the defender. What the attacker tries is to do better, by using specialized hardware which will allow him to hash N potential passwords for less total cost than if he were using the defender's hardware. The total cost includes the cost of buying the hardware, the cost of developing the relevant software on it, and then the cost of running the hardware, which basically amounts to the used electricity (for powering the hardware and for cooling it). For a serious attacker, the power cost dominates.
Whenever there is some operation that the attacker can do cheaper than the defender, the attacker wins. An important point is that password cracking is an embarrassingly parallel problem: by definition, the attacker has many potential passwords to try.
Suppose that you cascade three distinct hash functions
Hash3. This means that the defender must have all three implementations at hand, all running on his server. The attacker, on the other hand, can have a better scheduling: he can (say) hash one million potential passwords with
Hash1 and save the results in some buffer; then switch hardware to something that applies
Hash2, and run it over the million saved outputs from the previous step, there again saving the
Hash2 outputs in some buffer; finally switching hardware again, with
This kind of "hardware switching" is especially relevant when using FPGA: each "switching" is a reprogramming of the same actual hardware, and is a matter of a few seconds at most. By using such scheduling and buffering, the "switching" cost is negligible.
This can also be used as pipelining: if the attacker built three specialized machines, one for
Hash1, one for
Hash2 and one for
Hash3, then he can run
Hash1 on the first potential password, then send the output to the machine that computes
Hash2. While the second machine computes
Hash2, the first machine can compute
Hash1 on another potential password. And so on. In practice, the attacker can maintain all his specialized machines at full occupancy at any time, thereby laughing at your attempts at "increased strength".
Moreover, if there are three distinct hash functions to implement and only one of them can be optimized with specialized hardware, then the attacker still gets a win by optimizing that one. To say things crudely, if you cascade bcrypt, scrypt and SHA-256, then the attacker will use a PC for the first two, and a GPU for the SHA-256, and will thus avoid about 1/3rd of the cost.
To sum up, the intuition that "mixing a set of different hash algorithms should provide additional strength" is wrong. It does the opposite. Such mixing increases development and usage costs for the defender, while it does not slow the attacker (who has a lot of parallelism to benefit with), and increases the attacker's options for optimization.
(All of this is said without talking looking into practical things, such as the management for the individual salts for all cascaded functions, and the dangers of homemade cryptography.)