Truncation of salt may be ignored
defuse opened this issue · comments
An accidental truncation of the PBKDF2 output (at the end of the encoded hash) will be noticed because the length is stored explicitly. The same is not true for the salt. If somehow the salt were truncated accidentally, it would not be detected.
This is just a theoretical problem I noticed when doing an audit. I don't think it needs to be fixed, since the salt is in the middle of the string, and if we want our threat model to include accidental removal of parts of arbitrary parts of the string, I don't think that's realistic. So I'm closing this right away as "wontfix."
It may be worth exploring formal security definitions for password hash encodings, i.e. some sort of game where the attacker (who doesn't know the password) is allowed to modify the hash in certain ways, and then try online guesses (or whatever) in order to speed up their guessing. AFAIK no such model exists, but I don't want to create one as part of this project.