#1192 New/Changed Password Lost if Database Becomes Locked

[Gillum]

Can anything be done about this behavior?

1. Database opened read/write.

2. New entry created.

3. Database becomes locked before entry saved (e.g., because database configured to lock on workstation lock, and workstation locks on time-out).

4. Workstation unlocked.

5. Database unlocked read-only (because that is default).

6. New entry lost.

[James Walters]

This is a catastrophic error! And, now, with version 3.44, PasswordSafe crashes instead of just losing the entry! This bug and all related need to be put as highest severity and priority, as this goes to the true core of why to use Password Safe. I should not have to fear losing passwords that I created if I didn't save soon enough.

[Rony Shapiro]

Can you attach the minidump file generated by the crash?

[James Walters]

I'd like to, but this is a public forum, and I am more than a bit apprehensive that someone can take this file and somehow glean my unencrypted password data as this dumps all of memory, and this was a crash, not knowing exactly where in the decrypt processing this was. My database was open and was in the process of being modified and, not knowing what this code does, could it be possible that unencrypted data was present in memory at the time of this crash? I was actually modifying the password in an entry and had to go do something else. When I came back, I hit Apply to store the new password and that is when it crashed after the 5 minute timeout to lock the database. I have it set also to lock on minimize and lock on workstation lock, but I don't think the workstation locked itself when this happened, just the timeout to automatically lock the database. If you can't reproduce this crash with this information, please advise, along with some way of getting this dump file directly to you.

Again, this all seems related to the lack of a coherent way to handle the database being locked automatically while in progress of entering in new data; looks like a lot of issues related to this.

[Rony Shapiro]

Can you try reproducing the crash on a dummy database, without sensitive information?
If you prefer, you can mail the dump directly to me at pwsafe.org.
The config file would also be useful (this is a text file, you can review it before sending to see if there's something there that you'd rather would not be).

[MrMe]

I couldn't reproduce this using either of the following tests. I am using v3.44 64-bit in Windows 10.

1. open dB R/W, create entry and have dB lock due to idle timeout while on the Add/Entry dialog. Once I type in the password to unlock safe, I'm still on the Add/Entry dialog.

2. open dB R/W, create entry and have dB lock due workstation lock while on the Add/Entry dialog. Once I unlock the workstation, type in the password to unlock safe, I continue on the Add/Entry dialog.

I think more detailed information is needed to reproduce this. Not sure if this matters, but I am not using system tray for example.

[Gillum]

I posted this originally, and my recollection (which was correct) was that the problem was fixed (as MrMe notes).

The orginal behavior was that, after unlocking the workstation, you would have to unlock the database with the normal dialog box that allowed a choice between read-only and read/write. If you picked read-only, you were in trouble.

Now (I am running 3.42.01 because of bug 1440), the database-unlock dialog no long includes a checkbox for read-only versus read/write.

I assume that, when the database is locked, the workstation tracks whether it was in a state that required a read/write database (e.g., create-entry dialog open) and, in that case, forces the database to be read/write when it is next unlocked.

[MrMe]

Going from memory, but what I believe I had observed in my two test cases, which are cases where the DB is opened R-W and locked while the Add Entry dialog is open, is that the user doesn't get the option to open R-O or R-W. The user only gets to enter the safe password, which opens the safe in R-W as would be expected.

[Gillum]

I am still running 3.42.01, which I thought had fixed this problem (see above).

But it just hit me again:

• Open database read/write
• Change an entry, leave it open
• Lock workstation (I don't remember how)
• Unlock workstation
• Unlock database (no read/write box to check)
• Workstation open, entry closed, change lost

So maybe there are some conditions that still lead to this problem. I'll see if I can recreate.

[James Walters]

This just happened to me again and caused me some horrible problems. It didn't crash this time, but still lost my new password and I am having no luck getting the website where I have this login to reset my password. Here is what I do to reproduce this problem of losing changes, every time:

Make database R/W
Add a test entry and save it.
Open up that test entry again and generate a new password using the generator button or otherwise edit the entry
do NOT hit apply or OK; leave the entry open, open a browser or anything else that switches focus from the pwsafe set of windows and wait for the database lock timeout (mine is 5 minutes)
Now, after the database lock timeout, pwsafe disappears from the screen and goes back into the tray, locked, force minimized..
I hit "Restore" from the right-click menu in the tray and get a safe combination prompt, but with no checkbox for read-only.
I enter the password and passwordsafe comes back up with all windows as before the minimize, including the changed entry with all my changes still there.

BUT: password safe is "READ ONLY" now!!

Hitting "Apply" to save my changed data now seems to work: it pauses for the least amount of time and the the Apply button is greyed out, the entry window still showing all the changes.

I then hit OK, thinking I saved it all ok.
When I go back into this entry, the old data is there, and all my changes are lost to the bit bucket, impossible to recover.

Need to figure out why the password prompt has no checkmark, and provide one. and then if Apply is hit on a database that is read-only, some sort of dialog must show to either enter in the correct safe combination to place back in read/write or to cancel the changes (but LET ME KNOW ALL WILL BE LOST IF SO!!)

PLEASE fix this

[James Walters]

[Rony Shapiro]

Fixed in commit ca67aaafa.
Will be in next release.

[James Walters]

Awesome! Thanks, Rony!

[MrMe]

Rony, just curious, what was the issue that needed fixing? No matter what I tried I could not replicate this using 3.44.0 in Windows 10, but maybe it's because of differences between my settings in Options compared to what others with the issue have set in Options.

[Rony Shapiro]

The commit log entry should explain this:

BR1192 - Don't revert to r-o upon lock if editing

FR703 reverts original r-o state upon lock, as this is useful
in a mulit-user work env.
The implementation didn't take into account the scenario described in
BR1192, leading to an open edit window in r-o upon restore.
This fixes the problem by not switching to r-o upon lock.

[MrMe]

Ok, Thx. I did try the scenario in BR1192 (i.e. DB set to open read-only by default) but could not reproduce it. Maybe some of my other settings in Options made a difference.

[James Walters]

Can you also not reproduce based on my scenario in my comment above ( https://sourceforge.net/p/passwordsafe/bugs/1192/#7e53 ) ?

[MrMe]

Correct. I could not reproduce using your scenario using v3.44.0 in Windows 10. What are your Options settings?

[James Walters]

Rony, if I may, your solution for this does not seem to be optimal. It ends up leaving the database not locked and not read-only for as long as an open edit window exists, which seems very insecure to me and defeats the purpos of the automatic locking. Much better woudl be to still allow the lock and switch to read -on ly, but intercept any attempts to save the changes in the edit window when it is locked again and allow the user to enter the password again or cancel the changes already pending (with a prominent warning that they will be lost forever if canceled). Your change leaves a security hole if I walk away from the machine forgetting that I have an open edit window.

---

[MrMe]

James, I'm so far not seeing what you are seeing...the DB that is opend R/W locks for me when left it idle on an Edit Entry screen using v3.45pre just like it did using v3.44.0. The password dialog to unlock the DB after the DB locks does not have checkbox option to open read-only or not and when the DB unlocks it is in R/W mode and I can continue on the Edit Entry screen with any changes I want and save the entry with no issues.

A suggestion. Can you try a clean install of Password Safe on another machine that doesn't have it installed and test again.