You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I understand how the Challenge-Response-Applet on the YubiKey works is: if you provide the YubiKey with the same challenge, you receive the same response.
I don't know exactly how KeePassDX handles things, but I assume during creation of the database, it concatenates (and probably hashes) the to be entered password and the response to a static challenge (probably randomly generated string stored on Android device? Plaintext? In its hardware wallet / enclave?). At least that's how for example dm-crypt/cryptsetup/luks does it when being used with a YubiKey.
That means: once $entity became aware of the response received from the HSM/YubiKey (assuming the challenge is a static string), the second factor is known and decrypting credentials from this very database does not need the HSM/YubiKey itself anymore.
It obviously could be, that there is its very own challenge generated and saved for every saved password, which would significantly improve things. But I didn't find any information about it.
Documentation/FAQ speaking of "master key" and "Yes, It is currently possible to unlock a database using your Yubikey." suggest, though, that this isn't the case.
Pointers and clarification would be highly appreciated! Respective documentation even more! Thanks! :)
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
As far as I understand how the Challenge-Response-Applet on the YubiKey works is: if you provide the YubiKey with the same challenge, you receive the same response.
I don't know exactly how KeePassDX handles things, but I assume during creation of the database, it concatenates (and probably hashes) the to be entered password and the response to a static challenge (probably randomly generated string stored on Android device? Plaintext? In its hardware wallet / enclave?). At least that's how for example dm-crypt/cryptsetup/luks does it when being used with a YubiKey.
That means: once $entity became aware of the response received from the HSM/YubiKey (assuming the challenge is a static string), the second factor is known and decrypting credentials from this very database does not need the HSM/YubiKey itself anymore.
It obviously could be, that there is its very own challenge generated and saved for every saved password, which would significantly improve things. But I didn't find any information about it.
Documentation/FAQ speaking of "master key" and "Yes, It is currently possible to unlock a database using your Yubikey." suggest, though, that this isn't the case.
Pointers and clarification would be highly appreciated! Respective documentation even more! Thanks! :)
The text was updated successfully, but these errors were encountered: