4 ms·
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
by saulrh 9y ago
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 9y agoIf you're using a keyed hash, then dictionary attacks can't be parallelized.
- Terr_ 9y agoWouldn't you want to use a salt instead?
- rocqua 9y agoYou 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_ 9y ago> 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.