#2743 Restore from history in a copy resets the creation date of the entry

[Ulrich Windl]

I have a complex password that I can't remember, and it is used to sign in in Windows Remote Desktop.
As it seems I cannot use the clipboard for username and password, so I must use auto-type to fill in the password at least.
So the sequence is {username}{tab}{username} at least. Unfortunately if the password expires, you must enter the new password in a rather short time, because otherwise the connection is terminated and you must log in again using the old password.

I fell in a pit: After having logged in with the old password, I used the password generator to create a new password, but I also had to change the auto-type sequence to send just the {password} (twice). As I did not manage that within the short time, I was logged out and I would need the old password again.

So I copied the entry with the new password, and in that copy I restored the old password from history.
Unfortunately I realized that restoring the history also changed the creation timestamp of the copied entry to that of the original, and it restored the name, too, so it seems I ended up with two identical entries.
Obviously that's not desired! (Seen in KeePass 2.50)

[Paul]

See this thread for password change method suggestions.
https://sourceforge.net/p/keepass/discussion/329220/thread/93c4cf59/#581c

cheers, Paul

[wellread1]

So I copied the entry with the new password, and in that copy I restored the old password from history.

• You didn't need to copy or restore the entry to copy the old password. You can copy the old password while viewing the history item containing it.
  

• Copied entries are new, entirely distinct entries. They are assigned a different UUID (universally unique identifier). It is appropriate for the a new entry be assigned a new creation date corresponding to the date the copy was created.

[Ulrich Windl]

I still think it's a bug to reset the name and creation date of a copy when the history is copied and then restored: The name looses the "Copy" tag (when present) and the creation date is set to that of the original entry. As the copy gets a new UUID (and that ID is kept), I see little sense in dating back the creation date after the time when the (new) UUID had been created.

For example the copy created yesterday had a creation date of January 2022 after restoring the previous password.

On getting the password from the history without restoring: It's a bit tricky, because I would have to add a second (for the same window title) auto-type rule to the entry, and then move the new rule on top to make it match first. Then I would move it down the list again to make the other one match. So I guessed restoring the password history would also remove my new auto-type rules; thus I thought I need a copy. Things would be much easier if the RDP client would change the window title if a password change is required...

[wellread1]

A restored history item should be a faithful copy of the original user data. The history item did not contain the data "Copy" in its Title, it should not be added.

The entry's creation date is metadata. There is a better case for keeping the current entry's creation date when restoring a history item.

You are making work for yourself by trying to automate a failed workflow. Just copy the old password from the viewed history item, paste it in the field for the old password, and finish the change password sequence. Since you won't need to restore the history item, or make a copy of the entry, no cleanup is required.

[Ulrich Windl]

Not quite: As stated for the original issue, mstsc.exe (at least as configured here) does not allow pasting, and also when trying to drag a value into a field I only see a "no entry" cursor, so it does not work. The only thing that works is auto-type.

If mstsc.exe would change the window title to "... Login ..." when logging in, and to "... Password change required ..." when a password change is required, then things would be much easier for auto-type.

Apart from that it's not obvious how to copy the password field from the history entry: If I double-click the password in a history line, the whole entry opens in view mode. I guess I'd have to display the password in cleartext, mark it, and then copy it. That's too complicated IMHO.

Maybe a "selective history restore" would really help here, and you could easily "mask out" undesired things like the "name of the entry" and the "creation time" (Remember: When restoring the history of a copy, the name and the creation time will be that of the original, making it really hard to find out who is who after that). Such a mask could be useful when creating copies of an entry, too, BTW.

[Paul]

That's too complicated IMHO

Which is why we have alternatives in the thread mentioned above.

cheers, Paul

[wellread1]

Apart from that it's not obvious how to copy the password field from the history entry: If I double-click the password in a history line, the whole entry opens in view mode.

The view mode is a functional view. Unhide the password (button with three dots to the right of the password field), then select the password and copy it.

If paste into mtsc.exe does not work, then you will need to paste the old password into an entry from where you can auto-type. There are a number of ways to accomplish this task. For example:

• Create a temporary entry and paste the old password into the password field. Select the entry and auto-type the password from this temporary entry using the additional auto-type commands. To enable additional auto-type command check Show additional auto-type menu commands in Tools>Options...>Interface(1)>Main Window(section). The additional Auto-Type commands will be available in the menu Entry>Perform Auto-Type ►. Delete the temporary entry once a successful password change is completed.

• Add a string field to your RDP entry called something like 'old password'. Paste the old password into the string field. Once you have successfully changed the password you can leave the 'old password' string field in your RDP entry for future use.

  • Use an plugin such as KPEnhancedEntryView to auto-type directly from the string field into the mstsc.exe old password field
  • or define an auto-type sequence in the RDP entry to auto-type the value of the 'old password' string field into mtsc.exe.

[Dominik Reichl]

I've now added a 'Copy Initial Password' command in the tools menu (which is displayed when clicking the 'Tools' button) of the entry dialog. It copies (to the clipboard) the password that was current when the dialog was opened.

Here's the latest development snapshot for testing:
https://keepass.info/filepool/KeePass_220811.zip

For more complex password change procedures (e.g. involving auto-type), you could use the 'Password Change Assistant' plugin.
https://keepass.info/plugins.html#pwchange

The history entry restoration will not be changed, because in my opinion it's working exactly as it should.

Thanks and best regards,
Dominik