In that paper they're concatenating two hash outputs which obviously (right?) only makes it easier to reverse the hash - the attacker need only pick whichever h

In that paper they're concatenating two hash outputs which obviously (right?) only makes it easier to reverse the hash - the attacker need only pick whichever hash he can work with quicker, and find the preimage for that. Given the fact that password entropy is much lower than hash entropy, the preimage thus found is almost certainly the original password, not a collision - rendering solving the other hash preimage moot. If you want to force the attack to go through two hashes, you'd use functions sequentially (e.g. F(G(input)), not F(input)+G(input)), which the paper at least initially doesn't talk about. I didn't read the whole thing, mind you... Note that password-stretchers like bcrypt/PBkdf2 use only fairly small extensions to this idea, so clearly in general the construction isn't known to be flawed.