keechallenge
keechallenge copied to clipboard
brush701
Use the new KDBX 4 custom header rather then XML
KDBX 4 (finally) has a custom header area that may be used by plugins: http://keepass.info/help/kb/kdbx_4.html#exthdr
This sounds like a wonderful place to keep the XML data in and get rid of the inconvenient XML file.
I would like to add comment on just how important this request is i imagine to the community at large.
Presently, you cannot use a combination of KeePass + KeeChallenge + Database Synchronization Tools (for a backup of your database) -- as none of the synchronization tools can also sync an external XML file.
To my knowledge KeeChallenge is also the only tool which can allow multiple2Factor Authentication hardware (aka a backup) such as a Yubikey.
If the information within the xml file can now become integrated into the database itself, this allows for a much more robust and secure toolkit for not only keeping your passwords database secure from keylogging, but also secure in its integrity at multiple save locations.
I am not so much a coder, but if i can help in anyway, such as testing with a yubikey or such, i would like to assist in any way i can.
@CRC32-809d908e , so currently database synchronization is not supported with KeeChallenge? I was just considering adding KeeChallenge to my Keepass (just bought my Yubikey) but if that breaks synchronization it would be a showstopper for me. :/
@strasharo if you mean using the built-in keepass sync. mechanism: it depends. It will not sync the .xml file that contains the encrypted key. However: that's not required. It should work even if the .xml is not synced. You only have to make sure that each client has a keechallange xml. Everytime you open it the challange will be changed (the composite key secret stays the same). But it's fine to have "different" challanges on different clients.
In fact: due to replay attacks it's even better to not have it synced.
@strasharo i want to clarify
My ideal use would be to have a Primary Yubikey and a Backup Yubikey. KeeChallenge is the only plugin currently allowing 2-Factor plugin AND will work with multiple and or backup Yubikeys. Likely many organizations would desire a similar setup: of a Yubikey for each team member and a backup in a safe) + Synchronization to alternate/safer locations.
currently (keechallenge v1.5.0.0 and prior) when using database synchronize mechanism/plugins to other destinations -- the database will synchronize, but the .xml file will not synchronize.
What this means is that if you need to use the database from a synchronized destination, you will need to use the composite secret.
From a security best practice standpoint, one would NEVER want to use the composite master, that should be stored in a safety deposit box or stored as parts of Shamir's Secret Sharing.
@m451 Unless i am not understanding the mechanism of a replay attack, how it would be safer to have the .xml file external? Specifically what is being replayed?
There are certain limitations to what 2FA can guard against -- at some point you're just plain owned -- such as whats outlined in this commentary:
https://github.com/brush701/keechallenge/issues/22
But.... I could see where some organizations would prefer a backup destination NOT have the xml file, to better help guard against employees walking off with the DatabaseCopy + "lose" their yubikey.
Perhaps a checkbox would be ideal: Save info within .xml OR Save info within the database
I have personally looked into this and its not simple. The database is not yet loaded by the time the key function is called. As such even if you could save the data in the kxdb you could not easily retrieve it in the current version of KeePass in order to actually do the key decryption
Just wondering if there is any progress in this matter? External non-syncing XML outside of KDBX is also a show-stopper for me.
I looked into the issue and posted a question on the KeePass board and was basically told its not possible within the KeePass framework. The header is not available before the database is decrypted at least within the KeePass framework so even if I could store data there unencrypted I could not retrieve it whenever i needed to decrypt again without making a custom parser.
I have two solutions I am working on however to get around requiring the XML sync, one is to request a password from the user that is combined with the result from the YubiKey so no XML is required and another (although poor) option is to use something like a hash from the KDBX as an input. One change I have made on my own branch at https://github.com/whinis/keechallenge is not requiring the secret key of the yubikey anymore. I am open to other suggestions however.
EDIT: Note, I also cannot grab the password from the input form it has to be another password
Hi John, Asking user for the password and adding the response from YubiKey is actually a working option. I could life with that. Although, ideally I'd like the hardware key to replace any typing at all.
@0anton Its less adding the response from the Yubikey and more for the Yubikey to work as it currently is in this mode it needs some common challenge. Currently that challenge is saved within the XML file which is almost the only reason the XML file is needed so if the user inputs the challenge manually then no need for the XML file or if there is a way to get a consistent challenge from the KDBX file then no XML file is needed.
It's called second factor for a reason. Personally I do not want anyone who has phyisical access to my Yubikey to gain access to my KeePass. KeePass does emphasise this, saying that plug-ins might be used as an additional factor to build the composite master key required to unlock the KeePass database. Quote:
To open a database, all key sources (password, key file, ...) are required. Together, these key sources form the Composite Master Key.
So the discussion should be about how to make that second factor use as convenient as possible. Removing the requirement of a additional file seperate from the database would make moving and syncing the database much more convenient for users.
Altought, since YubiKey now supports FIDO2, maybe there are more elegant methods to implement a second factor then challenge-response based on HMAC-SHA1 and get rid of the xml all together. Not sure if that would be a topic / direction for this repo, or if a new implementation would make more sense.
Sorry I was away on vacation. @m451 Honestly I would almost shoot for another implementation at this point. But in my brief looks at FIDO2 I am not sure exactly how I could implement it. One of the defining characteristics that a KeePass auth plugin needs is that the input for the master key should be the same each time. I am not sure currently if there is any current AuthProvider that doesn't use some external file be it a certificate or xml file if you know of any please let me know.
@m451 The discussion was had https://sourceforge.net/p/keepass/discussion/329220/thread/9ca8e503/?limit=25#8c61. While I could add in a custom header reader based on the source code for keepass the maker of keepass suggest against it.
Hm, yes. Well Dominik deosn't seem to be the easiest person to talk with about new stuff / changes. I guess that explains the number of forks.
Also I don't really understand his "DB read from disk" argument. Why not just load the DB file into memory and then access the different DB sections - encrypted / unencrypted - as you like?
But thanks for talking with Dominik and trying to figure out if this suggestion is even suitable.
I do not have an answer for you and adding a second reader in the plugin seems less ideal that I would like. If you can convince him to add something similar to that I will collapse everything needed into that header probably overnight on my own github.