Commutative Hash Function for Password Challenge?
If you are storing $h_1(password)$ and I break into your database, I will simply sort all the hashes I find. The one that appears most often will be $h_1($"123456"$)$, closely followed by $h_1($"password"$)$. In other words: you're storing unsalted hashes.

This is why you use special key derivation functions like scrypt and not plain cryptographic hashes on passwords.

If you are doing a man-in-the-middle attack, you generate your own key $k$ and send it to the user, who replies with $h_2(k, password)$. You know $k$ (this is still the case if you use a "trust-less protocol" to agree on $k$) so you can now try $h_2(k, x)$ for all $x$ in the 10 million most common passwords list at your leisure - even without breaking into the server.

If we're talking about key-based authentication, where collisions are unlikely to be a problem, there is an authentication protocol that uses a commutativity property a bit like you mentioned: Schnorr ZK proofs.