search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
20.78k stars 1.44k forks source link

Do not ask for the hardware key after the initial unlock #9089

Open FrAllard opened 1 year ago

FrAllard commented 1 year ago

I wish I would not need the hardware key everytime I unlock the database.

Here how I see it.

First time I open the database after a reboot I have to provide the master password along with my hardware key. Then I give it my Windows Hello credentials.

When the dabatase lock itself or I lock it, from that point I'm being asked only Window Hello, recently I added a Yubikey and I found out that I need the Yubikey constantly connected to my computer to use KeePassXC.

I wish I cloud give it the key once during first unlock and once Windows Hello has been enabled I should not need to connect my hardware key anymore, until the next reboot (or disconnection).

Keepass2android does it exactly like that. If QuickUnlock gets upset it's going to ask for the hardware key, but if I keep QuicUnlock happy I only have to present my fingerprint to unlock and modify the database.

droidmonkey commented 1 year ago

KeePass2Android must not be cycling the challenge on every save like we do. Basically, every time you save your database in keepassxc a new challenge is generated which requires a new response to be baked into the master key. This is why you need to keep your hardware key plugged in.

Can we save the hardware key response as part of quick unlock? We sure can. However, once you modify your database you will be unable to save it without the key inserted.

FrAllard commented 1 year ago

I could live with that. Keeping the database easily unlockable with the QuickUnlock in read mode. Then if I need to modify and save I would provide the hardware key.

QORTEC commented 1 year ago

And that also makes sense on a permissions level; ts common (even expected) to need to elevate your privileges when attempting to edit critical information. Though that may be my FreeBSD/Linux experience speaking.

GrimzEcho commented 2 months ago

KeePass2Android must not be cycling the challenge on every save like we do. Basically, every time you save your database in keepassxc a new challenge is generated which requires a new response to be baked into the master key.

@droidmonkey -- Is this done to prevent replays of a previously calculated HMAC-SHA1? I assume that if the response is intercepted after the saving of a database then it can be replayed to that same database until the next time it is saved (and a new challenge generated), after which it could no longer be used.

I can confirm that Keepass2Android does not require use of the Yubikey after making changes to the database. Assuming a shared database file between KeePassXC and an implementation that does not cycle challenges, is there a scenario where the database file gets saved in a way where the other software cannot open it? My guess is that the plan-text challenge is stored as DB metadata using just the password as an encryption factor so as long as the password hasn't changed the software will always send the "correct" challenge regardless of whether it has been cycled or not.

Is that accurate?