#707 High-security option to not include password hash in database/file

wont-fix
nobody
None
1
2013-08-16
2013-05-31
Tim H
No

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

Discussion

  • JackG

    JackG - 2013-06-07

    You can see here for details on the encryption process.

     
  • Rony Shapiro

    Rony Shapiro - 2013-06-07

    Er, two wrong assumptions here:
    1. There is structure in the database that's enough for an attacker to determine if a given key is correct or not. Furthermore, it's not necessary to decrypt the entire database for this. This isn't unique to PasswordSafe's database - any correctly decrypted text is significantly distinct from incorrectly decrypted text.
    2. PasswordSafe does not use a simple hash, but rather an iterated one (hash of hash of hash of ...). The number of times the hash is iterated is part of the format, and is currently set by a compile-time parameter - a couple of thousand or so, IIRC. This is the main line of defense against increasing hardware capabilities.

    Perhaps an advanced option to increase the number of iterations would be more effective?

     
    • JackG

      JackG - 2013-06-09

      "Perhaps an advanced option to increase the number of iterations would be more effective?"

      I was actually just thinking about that yesterday. I noticed KeePass offers that option, and even provides a convenient clickable link that computes the number of rounds that lead to a delay of 1 second on the host machine.

      This would be great for enhancing the security. I noticed in the link I posted above, you mentioned the current number of iterations is set to 2048. Isn't this a little low? The default on KeePass is 6000, and LastPass uses 100k. For my particular machine, KP calculates 3,506,688 iterations would lead to a 1 second delay.

      Is this option something that could be implemented?

       
  • Tim H

    Tim H - 2013-06-09

    While increasing the iteration is good and a very effective way to increase security, I would still like to consider the --high-security option as I previously outlined it.

    I currently use a tool called "BURP" that I downloaded many years ago that uses Blowfish to encrypt files without any kind of header in the output. It would be very nice to be able to use Password Safe for this function instead.

    I suggested leaving the header on the output file and replacing the password comparison hash with random data as a way to simplify the coding. The GUI portion can remain unchanged and only a small change should be needed to the encrypt and decrypt functions to add the random data and to not check the decryption password against the data in the file, respectively. I'm not sure it is a "win" (since it breaks "plausible deniability), but having a random comparison hash means that anyone who thinks they've decrypted the file by relying on the hash to prove decryption will be guaranteed to not have the original file.

     
  • Rony Shapiro

    Rony Shapiro - 2013-08-16
    • status: open --> wont-fix
     
  • Rony Shapiro

    Rony Shapiro - 2013-08-16

    The next version of the format will not have an easily detectable header (or suffix). However, the alternative to no iterated hash to verify the password is to let the app crash if the wrong password is entered, which the attacker can try in any case, but which doesn't exactly enhance the user experience.

    PasswordSafe was not designed to provide 'plausible deniability'. If you need that, the hash is the least of your problems (and you might want to look at TrueCrypt...).

     
  • Tim H

    Tim H - 2013-08-16

    That might be enough. "Plausible deniability" is not what I'm seeking -- although it probably works out to almost the same thing -- but it would be "nice" if it dropped out for free. Mainly, I just want to be able to save PWS databases and encrypted files to the cloud, or send them as email attachments, without providing any clues whatsoever to the bad guys to help them decrypt the files.

    I am aware of TrueCrypt and use it extensively. However, a solution for individual files is still highly desirable. Creating a TC volume just to contain a single file is not really a practical solution.

    Thank you for being so responsive to input. It is, unfortunately, not all that common in the open software realm. I also want to thank for all your work.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks