David Matson

Thanks, Dominik. To clarify, persisting key sources in the database file is not required by the format above. Instead, it allows users an option: 'Remember key sources (...) in database file.' For users who do not select that option, a key protector type of 'Undisclosed' would preserve current behavior. Whether there is a usability vs. security tradeoff is an interesting question - I beileve for most users there are better ways to improve strength than not persisting configuration data, as discussed...

I should also clarify that I'm not suggesting we support multiple master passwords or multiple recovery keys directly in KeePass - I think that while the proposed format could support it, that scenario is more niche and more likely to confuse users. I think the recovery key idea is one that seems more broadly useful to me, and would motivate changing the format to add the data encryption key concept. In other words, the proposal here would be to add the data encryption key / key protectors to the...

Thanks, Dominik. Agreed that this data (including, in theory, data about what methods are needed to unlock) could be placed within the key protector plugins and custom data portions of the existing system - first-class support seemed like it could be simpler and more broadly compatible. Any thoughts on the idea of having the methods use to protect the DB be included in the file format, so they are discoverable in the UI? For example, for users who only use a master password, and not DPAPI or a key...

Context: I have multiple YubiKeys, and would like to be able to use them, without any other master password or other key data, to unlock my KeePass database. If I were to lose them, I would like to be able to use a separate, randomly-generated recovery key (which I can print and store in a secure location) to unlock the database. Additionally, I would like the KeePass database file to know what the valid options are to unlock it: "YubiKey ABC" or "YubiKey DEF" or "Recovery Password". Note that these...