Only Key is referred to as a hardware challenge-response token. Additionally, the help tip on the unlock screen could be introduced to the master key setup dialog.
No reference to Only Key
No we still need to place the help tip on the master key setup dialog.
I think it is only needed to exchange text on Master Key tab and add clickable link there. But, will add the help tip (?) as You desired.
Another thing come up. After setting Chall-resp. up there is need to activate Yubi two times.
Is saving DB right after setting up Chall-resp. is desired? Is UI prompt delay desired?
Video reproduction attached. GH not accept video so it was compressed.
That's because the first time KeePassXC is benchmarking the KDF rounds for your machine, the second time it's doing the actual key transformation. Maybe the benchmark could be done with a dummy key.
:+1: for the reasoning. Maybe just save on key change? That will be done with password + license file automagically.
More, on the KeePassX there is tester for it and you choose it. Why KeePassXC should decide while changing key how many rounds somebody want to use?
The number of rounds is only benchmarked once when you create a new database.
So, I will look into fixing issue today.
Offtop:
The number of rounds is only benchmarked once when you create a new database.
Thanks @phoerious I must look into the code today, because my comments then will lead to nothing forward.
As far as I understand both your comments they say things:
1) after changing DB credentials (i.e. add Chall-resp) then you recreate DB in memory (if not then why benchmark take place because of not creating new DB with same content but different creds?)
2) every re-creation of DB in-memory is benchmarked while this re-created DB cannot be saved to disk
I know near nothing about file format used by KeePassXC so sorry if I mess things up in comment below:
One thing come to my mind. If we have unlocked (== unencrypted?) DB in memory while using KeePass that could be dropped in memdump during working with DB (until locked and wiped from memory by overwrite or HW restart), or we hold some keys to decrypt it while it is needed. I think first.
What about, having file with some metadata always found in memory unencrypted after unlocking (DB tree structure with names/emails of items in it) and then when requested (ctrl-c in UI and so on...) decrypting 2nd part of DB only for this purpose and wiping just after decryption.
Thanks again @phoerious for any comments, clarifications and infromations provided to me, because I am complete newbie in this project. Really sorry if I missed some 'let me google it for you' case or docs/source internals low hanging fruit.
Kind regards.
When you create a new DB, we benchmark for 1s decryption time during the creation dialogue. That is when you have to touch your YubiKey.
Following that, we transform the key every time you save the database, where you have to touch the key again. Saving occurs once after the new DB has been created and after every modification of its contents. Each transformation takes about a second and requires YubiKey interaction if you configured your YubiKey for it. If not, the YubiKey will still be challenged, but without the need for manual intervention (my preferred mode).
Wow, does YubiKey allows other than "electrodischaging"-way to activate that? Good to know. Thanks @phoerious
You can program the HMAC-SHA1 mode to be non-interactive.
I have seen that it use some weirdeness of it's Qt's UI scheme but also inlines.
Should there be like very simple boxes with header on border as now and:
Best regards
cc: @phoerious or @droidmonkey ?
I am editing this code right now and will make the necessary changes.