"Double click to edit" possibly misleading

[s-h-a-d-o-w]

I just updated two of my throwaway passwords through the breached passwords dialog and when I was done, I lost access to those services because as it turned out... Keepass didn't actually store the edited passwords.

The odd thing is - after editing the passwords, I double clicked the entries again to double check whether the passwords had really been changed. And they were there. So... somehow, the passwords get updated in the breached passwords dialog but aren't transferred to the actual database.
Might it have to do with the fact that Keepass locked itself in the background while I was editing the passwords?

Anyway, - if you can't ensure that the edited passwords actually are updated in the database on closing the dialog, I think that it would be great if you could warn the user in bold red text or not allow editing from that dialog from the get-go...

[andrew-schofield]

Double click to edit should be opening the entry in the database not a copy from the breached password dialog.
Did you try opening the entries from the main keepass window after closing the breached entries dialog?
Also, editing entries will not automatically save the database.

I'm unsure how you determined that keepass didn't store the passwords.

If the database locks itself in the background then this definitely is a problem, the dialog should ideally be disabled until then database is unlocked again.

[s-h-a-d-o-w]

Alright, my process step by step:

• double clicked an entry from the breached password dialog
• went to that website, the change password process
• generated a new password, displayed it in plain text so I could copy it from that window
• finished the change password process on the website
• clicked OK on that editing password window
• did the same with the other password
• closed the breached entries dialog
• tried logging into one of the services using the global hotkey and it tried entering my old password (which I immediately realized because it was just ~8 characters instead of 20)
• opening the full database and double checking the password confirmed that it actually wasn't updated

[andrew-schofield]

Interesting, so I just tried to replicate this with a dummy entry which I know has a breached password.

• Double clicked entry in breached entries dialog
• Changed password to a known new password
• Clicked OK on edit password window
• Closed breached entries dialog
• Autotyped into a new text editor window (CTRL-V), it entered new password
• Opened entry from main database window and confirmed that new password was stored.

I'll need to test this again to see what happens when the database is locked while the breach dialog/editor dialog are open.

[s-h-a-d-o-w]

Well... that workflow makes you return quicker from the breached password dialog to the main window but it still assumes that you do that within your set "lock time". Which is 1 minute in my case...
(And apparently, you can't assume that everybody does things the way you do them. ;) )

But I suppose the breach dialog getting disabled when the database locks would indeed be one way of resolving this... in my case, it obviously stayed enabled.