#2175 KDBX4 - Save the Master Key composition in the database.

[wellread1]

Save the Master Key composition in the database.

This suggestion is directed at assisting the average or new KeePass user. It also creates an opportunity for KeePass to present a more streamlined (less cluttered) Enter Master Key dialog.

Average, and new users, are reasonably likely to create multi-component Master Keys without much justification other than it is easy or convenient to do so. It is relatively easy over time, for the such a user to lose track of the composition of their Master Key. This poses a serious complication for the user faced with the stressful "The composite key is invalid!" error message when the user is uncertain of the Master Key composition, or worse, certain of the wrong compostion.

If the Master Key composition is saved in the database, it can be used by KeePass to mask the unneeded fields in the "Enter Master Key" dialog eliminating ambiguity regarding the number and type of secret(s) required to open the database.

Saving the Master Key composition in the database has the additional advantage that KeePass can use the data to simplify the Enter Master Key dialog on a per-database basis (unlike the UIFlags option). Saving the Master Key composition may also create new possibilities for streamlining automatic database opening since the Master Key composition will be available to KeePass during open/unlock.

Since the Master Key composition is defined on the Create Master Key dialog, this dialog is a logical place for the an option 'Save Master Key composition'; on by default. Users that object to saving the Master Key composition would have the option to not save it. by unchecking 'Save Master Key composition' and KeePass would presumably behave as before.

[Paul]

I see problems in a recovery environment where drive letters / WUA are different. You still end up being unable to unlock the database but are no closer to knowing why.

cheers, Paul

[wellread1]

To clarify, I am suggesting only that the types of secrets be recorded, not data such as key file path. Just the fact that a Master Key consists of a password and the WUA, or password and key file is a huge amount of useful information to someone who is struggling to open their database.

[Dominik Reichl]

I'm not sure about this.

• Up to now, KDBX files store no information at all about the master key. From a security point of view, this is the best you can do. By storing the master key component types by default, the security of all users would be reduced by some factor by default; whereas only some novice users would benefit from it (when forgetting the components and moving a new PC). Of course, there's always the dilemma security vs. usability, but on file format level I strongly tend towards security (because it is a very likely scenario that an attacker can obtain a KDBX file, e.g. when a user puts his database into a cloud storage).

• Where do we stop? Sure, the component types can be a valuable information in case you can't open your database. Should we also store the length of the master password? Should we store the character types of the master password? Should we store the key file name or path? Should we store the key file size? Should we store the Windows account SID? All this information could help, but obviously the more we remember, the lower security becomes.

• Even if the component types would be stored in KDBX files, streamlining the master key dialog would be rather hard and likely would result in problems. Currently, the KeePass UI obtains the KDBX file path and the master key, sends these two to the KeePass core, which tries to open the specified database with the specified master key, returns control to the UI, and the UI is updated accordingly (showing the database in the main window or showing an error). For streamlining the master key dialog, information about the master key is required before showing the dialog, i.e. KeePass would need to open the database file before asking for the master key. This either requires roundtrips or dissolves the clear separation between the KeePass core and the UI, but more importantly we would inevitably run into file access problems caused by opening the file too long (e.g. server timeout during displaying the master key dialog) or multiple times (in case the file is closed immediately after reading the header, which actually might not be possible for all I/O methods).

• Would storing the component types in the configuration file be sufficient? Some users may copy their configuration file, some not. However, the configuration file already can store key file paths and information whether a user account was used for protecting a database; so storing whether a master password was used would be just one more piece of information.

Best regards,
Dominik

[wellread1]

Dominik thanks for the detailed response.

I did not appreciate that the sequence of events, i.e. Master Key dialog opens before anything is read from the database, would preclude making use of the key composition data stored in the database settings/header.

The suggestion to store the complete composition of the Master Key including whether a master password is part of the Master Key is a viable alternative. I assume you would include the data when the "Remember key sources..." option is checked.

A significant fraction of the users who have forgotten their Master Key composition may benefit and the potential, in some cases, to streamline database opening exists since KeePass can read the key composition when it retrieves the database path from the config file.

---

Your first point that meta data is security data in some contexts, e.g. when the database file is in complete isolation, is something to ponder.

[Paul]

We have no information on whether this additional information will help users who have forgotten their credentials. It might make our job easier when trying to help, but is of doubtful benefit otherwise.

cheers, Paul

[wellread1]

Key composition is directly relevant to the invalid composite key problem, so it can't help but be useful to some users who receive that error (especially those who have forgotten the composition of their Master Key).

Assisting with help is a not insignificant accomplishment. A user that is able, via help, to resolve their problem or reach a definitive conclusion about its source is less likely to be dissatisfied with KeePass. Additionally, a forum record that provides posts that have been definitively resolved, is much more useful to visitors experiencing the same problem than a record containing many reports of unresolved problems.

While we might be 100% satisfied that the 'The composite key is invalid' means exactly what is says, it doesn't mean that the forum record is convincing to other users. With KBX3 I am not 100% certain myself, because I don't have details about the nature and extent of the error correction, or authentication applied to the header (apparently it is saved in the encrypted body), I don't know what checks are done prior to generating the error message, and can't rule out the possibility of a bug. I do believe (have faith) any non-Master Key related alternative is extremely unlikely, and if something else is causing the error nothing can change the outcome anyway.

As I mentioned in the original post I believe there are additional benefits that can be derived from saving the key composition in the database e.g. simplifying the Enter Master Key dialog, and streamlining database opening for some key compositions.

Unfortunately, the fact that the Master Key composition data would not be available when the Enter Master Key dialog is displayed, eliminates the value that could be derived from saving the data in database.

[Paul]

I agree that it would be great to find a definitive answer, but I suspect that a user who has forgotten their master key wouldn't be helped by knowing what the master key comprised. In my experience in IT, the most difficult task was convincing a user that the password they "remember" is not correct, even though the system is showing incorrect password errors - you are effectively calling them a liar because they are convinced the password they "remember" is correct.

cheers, Paul

[wellread1]

the most difficult task was convincing a user that the password they "remember" is not correct, even though the system is showing incorrect password errors - you are effectively calling them a liar because they are convinced the password they "remember" is correct

But that is the point, being able to say the KeePass knows the composition of your key helps make the the case, and reduces the number of possibilities. And even if you can't convince the immediate user, other users can read a convincing argument.

P.S. I keep forgetting, the other optimizations I alluded to (simplifying the Enter Master Key dialog, and streamlining database opening for some key compositions.) can be implemented by saving key composition in the config file.

[Paul]

My implication was that even if they knew the composition they still wouldn't remember the parts they need to enter.

cheers, Paul

[Dominik Reichl]

I've now enhanced the 'Remember key sources' option. If turned on (which is the default), KeePass now remembers all master key components (i.e. whether a master password has been used, the key file path, the key provider name, and whether the user account has been used). When showing the master key dialog, all component checkboxes are initially set to the last, loaded state.

Here's the latest development snapshot for testing:
http://keepass.info/filepool/KeePass_161007.zip

Thanks and best regards,
Dominik

[wellread1]

Because the complete Master Key composition is captured in the config file, the possibility exists for a non-default option to automatically open a database without displaying the Enter Master Key dialog for those cases where a master password is not part of the Master Key.

I suggest this as a non-default option as opposed to a default option (or even standard behavior) because some users might find the behavior disconcerting. It really shouldn't be disconcerting, rather it is an indication of the effective amount of protection the user has implemented.

I don't see that pressing the OK button is a genuine security measure, even though it requires a physical presence, because starting KeePass or initiating a database open also requires a physical presence in normal operation. In any event, this objection is addressed by making the behavior optional.

The automatic open behavior would require handling an the edge case where the Master Key composition in the config file is incorrect, presumably by displaying the Enter Master Key dialog instead and suppressing the "invalid composite Master Key" error raised by reading the incorrect Key composition from the config file.

[Paul]

I've now enhanced the 'Remember key sources' option

I can't see how this differs from the old behaviour. Both 2.34 and the snapshot store key source information in the config file. I'm sure I've ;missed something, just can't see what.

cheers, Paul

[Dominik Reichl]

Previously, KeePass did not remember whether a master password was used or not. Now it does, and the 'Master Password' checkbox is activated/deactivated accordingly.

Best regards,
Dominik

[Paul]

Thanks