Keepassxc: TOTP secrets not saved if set up from within entry

Created on 26 Dec 2019  Â·  10Comments  Â·  Source: keepassxreboot/keepassxc

Expected Behavior

TOTP secrets saved

Current Behavior

TOTP secrets not saved if set up from within entry

Possible Solution

Steps to Reproduce

  1. Create new entry or open any previously created
  2. From WITHIN entry do Set up for TOPT
  3. Switch to Advanced(on the left) to see that "OTP" attribute NOT presented.
  4. You still can get TOTP code fine as until close/reopen DB.
  5. After reopen DB TOTP fully cleaned.

The only way it works correct(save secrets) if set up TOTP for entry from the main grid.

  1. Select entry (not drill down)
  2. Setup TOPT via right click menu or main menu.

Context

Debug Info

KeePassXC - Version 2.5.1
Revision: 0fd8836

Qt 5.13.1
Debugging mode is disabled.

Operating system: macOS 10.15
CPU architecture: x86_64
Kernel: darwin 19.2.0

bug high priority TOTP

Most helpful comment

I agree will fix

All 10 comments

Setup from WITHIN entry:
Screen Shot 2019-12-25 at 11 47 24 PM
Advanced attribute not created:
Screen Shot 2019-12-25 at 11 49 00 PM
Setup from main grid:
Screen Shot 2019-12-25 at 11 50 15 PM
Advanced attribute created fine:
Screen Shot 2019-12-25 at 11 50 42 PM
TOTP status is YES for both and works for both:
Screen Shot 2019-12-25 at 11 51 05 PM
Close and reopen DB causes TOTP clean up for TEST1 entry:
Screen Shot 2019-12-25 at 11 51 57 PM

Same behavior on Windows 10, so seems common issue.

I could have sworn to have tested this when I enabled the menu actions while editing an entry. This is an unfortunate side effect. The reason for this is because the entry object has a TOTP settings attached in code but not in the attributes (why it disappears on lock). I bet if you pressed "Cancel" to the entry editing the otp attribute would appear.

Right, just checked. If push "Cancel" it saves OTP, too complex pattern I would say for end users ). Might be better either disable TOTP set up within entry or make behavior consistent(which would be preferable).

Its a bug, not intentional pattern

Just hit this as well. Seems like a very dangerous bug — if the user does this and does not save recover codes or the secret key, they would be locked out of their account.

I agree will fix

I hit this bug as well and it will cost me 5€ to get access to the account again because there are no recover codes or secret keys available...

@droidmonkey Any update on this? I can confirm the same issue happens on KeePassXC 2.5.4 on Linux Mint.

Yeah I need to fix this for 2.6

Was this page helpful?
0 / 5 - 0 ratings

Related issues

shyim picture shyim  Â·  3Comments

n1trux picture n1trux  Â·  3Comments

rugk picture rugk  Â·  3Comments

shaneknysh picture shaneknysh  Â·  3Comments

clementlesne picture clementlesne  Â·  3Comments