First, let me admit that I haven't looked at the Password Safe code, nor am I a cryptographer. The following is based on the assumption that a hash of the password entered into the GUI is compared against a hash of the correct password stored in the file to determine that it is the correct password.
The availability, and continuing improvement, of GPU-accelerated password cracking tools significantly reduces the security of any encrypted file that includes a hash of the password (even if salted) for verification against the entered password.
I'd like to suggest a high-security option where the password hash field would be filled with random data. The password would be accepted as typed and used to decrypt the file or database without verifying it against the bogus hash. An incorrect password would result in a corrupted result which would be the only indication that the password was incorrect.
This would drastically increase the time required to "crack" a Password Safe database since the only way to check if a password is correct is to decrypt the entire database and check it for consistency. Even a "consistent" result could not be proven to be correct.
This also makes it effectively impossible to crack a file encrypted with the command line "-e" option unless something is known in advance about the structure of the file being attacked. Even then, I don't believe it can be proven that resulting file is, in fact, identical to the original.
Possible options for implementation:
- require that the password be entered twice to ensure it is not mistyped
- because this is an "advanced" and dangerous feature, require that it be specified on the command line (using a --high-security switch, for instance) and so shielded from typical users
- it would have to be made clear to users that an incorrect password will produce a corrupted result when using this mode
Log in to post a comment.