Security question

[fladd]

In this paper a specification detail of the psafe3 format is mentioned that 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 further mentions how the original Password Safe avoids this:

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.

How is this handled in Password Gorilla?

[rich123]

The line numbers below will be relative to the @804ff9dde70c68591c8010a1816250ea79fcd628 version that is the current tip of the new-features branch, but this code has not changed for a very long time so the numbers should resolve for versions going quite a ways back in time:

The passwordsafe file is written to disk (for the V3 format file) in a procedure in the pwsafe/pwsafe-v3.tcl file which begins on lie 867 of that file.

The routine picks a new salt at line 903 (the procedure pwsafe::int::randomString is defined in pwsafe/pwsafe-int.tcl at line 304 and returns random data from the Issac random number generator that PWGorilla uses.

At line 905 the code recomputes a new stretched key value and at line 906 it hashes that value (the hashed stretched key is the first part of the PWSafe file). Next, at lines 921-924 it retrieves 64 bytes of random data from the random number generator and encrypts those blocks using ecb mode and writes them to the file. Those new random values, newly encrypted, are then written to the file as the B1|B2|B3|B4 referred to in the PWGorilla source, or as K and L in the paper.

Then those newly created K and L values are used to initalize the encryption and hash authentication that is applied to the remainder of the data making up the password file in lines 952+ of the pwsafe-v3.tcl file (a new random IV is also chosen at lines 949-950).

So PWGorilla uses the method that the paper refers to as "less efficient, but secure" because new random K and L values are chosen each time the file is saved to disk.

The save code has been operating in this manner since before the code-base was taken over from Frank P. (PWGorilla's original author). I do not know exactly how long PWGorilla has used this method, but it has been quite a length of time in any case.

[fladd]

Great to hear, thanks a lot for the detailed answer!

Best,
Florian