3 ms·
The reason for his suggestion was to prevent an expensive hashing algo from being a means for creating a DOS, not to make the rainbow table attack any harder...
by crusso 13y ago
The reason for his suggestion was to prevent an expensive hashing algo from being a means for creating a DOS, not to make the rainbow table attack any harder... although if you offload an even more expensive operation to the client than you were going to perform on the server, it does make the attack harder.
- jessaustin 13y agoExcept an attacker wouldn't have to perform that expensive operation: she could just iterate over the range of the KDF. Unless there were rate-limiting!
- taejo 13y agoGetting them to iterate over the range of the KDF is enough, isn't it?
- jessaustin 13y agoWell I guess if the range is large enough it might not be feasible. But the hypothetical system is not rate-limiting (if it were, doing the KDF server-side wouldn't be a big deal), and it is not storing an individual salt, so time is the only thing standing in the way of this attack.
- taejo 13y agoTime is the only thing standing in the way of any attack (well, time and memory, I guess)
- oleganza 13y agoI assume that key was generated through an expensive KDF with a proper salt and is at least 32 bytes long. So "rainbow table attack" is out of question here. That's why I said sha256(key), not sha256(key + salt).