[saulrh]

That's what I thought when I read the title.

There's probably some reason it wouldn't work. Dictionary attacks are an obvious possibility; if your password is "password" the only thing you're depending on is nobody being able to get at the hashes. It might also expose password reuse, though nonces/salts might solve that. Hrm.

This smells a bit like public crypto - public database of public keys (hashes), on login you're challenged to produce proof that you have the private key (the password), and the transformation provides you a means to do that without exposing the private key itself.

[recursive]

If you're using a keyed hash, then dictionary attacks can't be parallelized.

[Terr_]

Wouldn't you want to use a salt instead?

[rocqua]

You use the 'salt' as the key in the keyed hash.

The difference occurs mostly when you start chaining hashes. In that case, a salt is only relevant in the first hash, whereas the keyed hash needs the key at every hash round.

[Terr_]

> You use the 'salt' as the key in the keyed hash.

I thought the two schemes were conceptually different, leading to different engineering tradeoffs: With salts, you assume the attacker can gain access to it. With keyed-hashing, you simply have a second piece of equally-secret information, and you hope it doesn't get leaked.