Issue #15 invalid

TOTP for KeePass Login

Anonymous created an issue

Hi,

Would it be possible to enable the ability to use TOTP to log into the KeePass database (i.e. use Google Authenticator to generate code to log into KeePass)? I know this is functionality is very different from generating TOTP for external sites, but I think this plugin is the closest/in-the-know-how of what it takes to accomplish this. This will remove the reliance on HOTP that Yubico uses that is easy to mess up if the sequence number is off.

Many thanks, Clement

Comments (3)

  1. Devin Martin repo owner

    The problem with that request is that TOTP (and one time passwords in general) are an authentication technology whereas KeePass really needs strong key management. One time password schemes all rely on a verification system that is tamper resistant (I.E. server side or even better HSM) to verify that a correct one time password was provided against a protected shared secret key.

    When you use a TOTP code to log in to Google, for example, Google is deciding weather to grant you access to their services or not. They have a server side implementation that looks up the shared secret key and verifies the code you provide. If you are able to provide a code that proves you have the shared secret, which they verify against the shared secret, they will chose to let you in.

    KeePass is a totally different platform. Everything runs locally on your computer. The password that you give (or keyfiles, or whatever you use as your credentials) aren't actually used to verify that you are who you say you are. These credentials are actually the encryption/decryption key themselves. While they bear a certain similarity to other password based authentication models, this is actually all about key management and not authentication. As KeePass is all local, there is no tamper resistant verification layer that one time password schemes rely upon.

    There are ways that HOTP has been forced to be used as key management, instead of its intended authentication, though I am highly critical of such schemes. This can be done by using what will be the next HOTP code as part of the encryption key and constantly rotating through them. It largely amounts to being forced to change your password (or part of the key in this case) every time you open the DB again but with some help to keep it straight. Using what is supposed to be an authentication technology to rotate keys is odd to say the least and there are more straightforward ways to secure the database. TOTP however couldn't be used in this manner as the passage of time means that the next code can't be known ahead of time and thus can't be part of the next key needed to decrypt the DB. The only other way is to have a non-tamper resistant authentication step in opening the DB. As this is all open source it would be trivial to bypass by creating a modified plugin without that step.

    Another component would be needed to make TOTP a valid part of a KeePass DB. There would need to be either a third party service, or a hardware device, that is a custodian of a part of the key needed to decrypt the KeePass database. If the user is able to provide a valid TOTP code, this key custodian would then provide their part of the key to KeePass to allow KeePass (along with other more standard key components such as a password) to decrypt the DB.

    Even more ideal would be a hardware dongle that is hardened physically which does the decryption for you if you can authenticate to it. In this way the key is protected in the strongest way possible. Neither KeePass or any system in memory ever even know the key thus the key itself (if not all the data) is protected from malware.

    You mentioned Yubico in your enhancement request. I haven't looked into it too much but a plugin that uses a Yubikey as part of the DB might have merit. Their challenge response mode (not HOTP but using the Yubikey as a key custodian that you must authenticate into) has been used by other password vaults as a part of the key. I don't know the technical details (their website is not forthcoming) but I am intrigued. Of course this neccesitates the purchase of a $40.00 device as a tamper resistant authentication/key custodian component. I'll look into that as an option and if I am happy with the security, I may write a Yubikey plugin.

    The third party solution is also an option. It could be structured in such a way that there is no less security than a password alone. That way one needn't worry too much about a part of their key being in a third party's hands. The third party would have no more luck cracking the DB than a casual hacker without such a scheme as the password and or keyfile (not to mention the actual encrypted database file) would also still be needed. However anyone else would also need to satisfy the TOTP verifying key custodian in addition to cracking the password and or keyfile. My heartburn with this solution is less about security and more about reliability. I'd trust myself to run it for myself, but as a KeePass user, I'd be worried about such a service going down and locking me out of my DB.

  2. Log in to comment