Is a new set of random keys generated in the file header when a change is made to the database?

[Anonymous]

I am asking the question after reading from this paper.

Here is the relevant section (under "4.8 PasswordSafe v3" in the paper):

However, we identified a design flaw that, although irrelevant in our security model, should be considered when adopting this format. The PasswordSafe v3 database format stores both the encryption key and the MAC key used to secure the database content in the file header. In this way, if the master password is changed, the database does not need to be re-encrypted. This technique is usually adopted by encrypted file systems to avoid having to re-encrypt all the data if the master password is changed. However, we believe that this choice may not be appropriate for a password database file. In particular, every time the database is modified, IV is changed and therefore the whole database is re-encrypted. For this reason, the reuse of the same values for K and L does not imply any savings. Additionally, this specification detail opens the door to an attack. Assume that an adversary is able to obtain the master password for an encrypted database. Using the master password, the adversary would also be able to retrieve (and store) K and L. Subsequently, even if the user changes her master password, the adversary can still decrypt and/or modify any new version of the database. The only way to recover from a compromise of the master password is to completely discard the database and create a new one, i.e., changing the master password serves no purpose. It should be noted that some implementations that use the PasswordSafe v3 format are not vulnerable to this attack (e.g., Password Safe [32]), since they choose a new random K and L every time the database is saved. This makes such implementations less efficient than they could be, but secure.

I find this fascinating, but I'm not technically minded enough to ascertain from the source code whether or not new keys 'K and L' are randomly generated in this implementation. Can anyone enlighten me?

I'm in the process of deciding which open source password manager to migrate to from LastPass. I'd really love some help here. If the keys aren't changed in the file header it won't necessarily be a deal-breaker for me, but I'm really curious!

[Santorio Debussey]

I created the original topic, but it is still in a state of "Post awaiting moderation" after three days. I'm going to try posting here now that I've created a sourceforge account. Below is the original post, and I'd really love an answer if anyone knows:

I am asking the question after reading from this paper.

Here is the relevant section (under "4.8 PasswordSafe v3" in the paper):

However, we identified a design flaw that, although irrelevant in our security model, should be considered when adopting this format. The PasswordSafe v3 database format stores both the encryption key and the MAC key used to secure the database content in the file header. In this way, if the master password is changed, the database does not need to be re-encrypted. This technique is usually adopted by encrypted file systems to avoid having to re-encrypt all the data if the master password is changed. However, we believe that this choice may not be appropriate for a password database file. In particular, every time the database is modified, IV is changed and therefore the whole database is re-encrypted. For this reason, the reuse of the same values for K and L does not imply any savings. Additionally, this specification detail opens the door to an attack. Assume that an adversary is able to obtain the master password for an encrypted database. Using the master password, the adversary would also be able to retrieve (and store) K and L. Subsequently, even if the user changes her master password, the adversary can still decrypt and/or modify any new version of the database. The only way to recover from a compromise of the master password is to completely discard the database and create a new one, i.e., changing the master password serves no purpose. It should be noted that some implementations that use the PasswordSafe v3 format are not vulnerable to this attack (e.g., Password Safe [32]), since they choose a new random K and L every time the database is saved. This makes such implementations less efficient than they could be, but secure.

I find this fascinating, but I'm not technically minded enough to ascertain from the source code whether or not new keys 'K and L' are randomly generated in this implementation. Can anyone enlighten me?

I'm in the process of deciding which open source password manager to migrate to from LastPass. I'd really love some help here. If the keys aren't changed in the file header it won't necessarily be a deal-breaker for me, but I'm really curious!

[Jeff Harris]

The app does create new random K and L keys on each save from the user's password. The code is in the PwsFileHeaderV3.java file. The salt and IVs, though, do not appear to be regenerated. I'm looking to compare vs. the base Password Safe C++ code. It looks like they regenerate them, but I that may have been an update at some point.

Jeff

[Santorio Debussey]

Thank you. Are there any significant security ramifications of the salt and IVs not being regenerated?

[Santorio Debussey]

Hi. I'm wondering if there have been any changes since I last checked in here. Is it still the case that the salt and IVs are not regenerated? (I'm not meaning to infer that they should be by the way). This is a great tool, and I appreciated all the effort which goes into it. Thanks.

[Jeff Harris]

I did an update quite some time ago to regenerate the salt and IV similar to the PC program.