[Suggestion]: Edit history, Solutions to 'The dangling new password problem'

[hgkamath]

Suggestion

Herein, I describe what I call "The dangling new password problem".
Hope to understand how everybody deals with it

This is a problem I experience on AuthPass. My only strategy is to be very careful and hope I don't screw up. The few times I have blundered I have been lucky to not get locked out. It helps that some websites have a 2FA and SMS/OTP mechanism to reset password. But there are websites where password resets can be a pain. I strongly feel this is a common problem to many users and one can experience the stress of it on any password manager that hasn't given enough thought to it.

Perhaps passy already has a solution or has a recommended strategy, a easily-followable-user-sequence, to guard against it happening.

The dangling new password problem ≜ There comes a time when a website/portal/account logs the user in and then asks one to do perform the periodic change of password to enhance account security. Passwords these days are long unreadable strings, ergo the need for password managers. The old password(s) are still required by the password change process, until the new password is in effect. Generating a new password in the text-entry spot of the old one, risks danger of a premature save/overwrite of the old one. Also, during this process, one needs to be able to see and have access to both old and new passwords. One does not want to be in a situation where one has a new generated password that is ready to be saved/applied, and yet one needs the old password to be available until one has confirmed that password change has succeeded, additionally to not forget to save/apply the new password after the password change has succeeded. Some websites are designed badly and one can have doubt whether the password change succeeded. In order to confirm that new password is in effect, one needs to logout and login. One can assume that new password is in affect only after this confirmation, only then one feels free to let go and delete the old password.

Expected solution:
Basically, one needs a way so that both old and new passwords are saved until confirmation.

Consider, what if the device that runs passy, (ex smartphone) crashes/switches off due to no battery, mid-process, while one is changing password on one's laptop.
This problem does not happen with pencil and paper, as on paper the old-password is still visible and readable until it is clearly-struck-out. With paper one has the trouble that if one forgets to strike out the old-password, the next time around one will be left wondering and may rely on spatial-memory to remember which of the two passwords is the latest.

Some manual ways around the problem is

1. Write new password on paper, then confirm it, be diligent enough to enter it. (not fully electronic solution, needs paper and pencil work, potential to forget to copy from paper)
2. Keep new/old password on smartphone's-clipboard, be careful not to lose clipboard contents. (easy to lose clipboard contents, clipboard juggling can be hard)
3. Generate new password separately and keep/type the new-password on a different lightweight editor (like notepad on the laptop) until ready to consolidate.
4. Keep new password in the password text box, make it visible by pressing the eye-icon, do not yet save in order to not lose old password, to keep textbox visible in order to see new password. (one can clumsily blunder)
5. Create a new entry each time, by copy-clone or copy paste old entry, make new password in new entry. Remember to delete old entry after confirmation.

There has to be a recommended, safe, idiot proof way to not lose the old password prematurely.
A good solution will reduce user-stress during password-changes.

Some possible in-software solutions:

1. One way is to have a edit history, but this could be over kill, no-one needs old passwords for ever.
2. Another way is to have a daily backup, but what if one changes a websites password more than twice in a day. Also opening viewing a backup needs a mechanism.
3. Ensure an easy streamlined workflow in order to execute the copy-clone/save-new/delete-old method
4. Have a concept of a new-edit-temporary-scratch-entry, that keeps data of an ongoing edit around until final confirmation. to nag user about unconfirmed edits, until finalized.
5. Have a concept of a previously-edited-scratch-entry that needs confirmation that it is no-longer needed. A fresh edit cannot be made unless the data in the previously-edited-scratch-entry is released to be not-needed/empty.

Submission checklist

• I have specified my suggestion in the issue title

[GleammerRay]

Hello @hgkamath ! Thank you for the well thought-out suggestions.

At the moment Passy offers automatic backups that can happen at periods as small as one second. The problem is that at the moment you would need to delete your older backups manually, as there is no automatic deletion feature. You also can't preview this backups in the app, you can only perform full restore.

Basically, one needs a way so that both old and new passwords are saved until confirmation.

#9 talks about a version control style feature for previous versions of entries. This should be somewhat easy to facilitate (e.g. create another file for each entry type, passwords_versions.enc, notes_versions.enc, etc.) and will also serve as a nice wayback solution that can be seen and used directly via the app (e.g. a "History" button shown for each entry). Note that #9 will probably not be implemented for the next release as I am planning to create some tutorials and to further polish the app so that it's ready for the Play Store release, as well as the unfinished files and attachments feature still being the priority afterwards. #9 deserves an update of its own.

this could be over kill, no-one needs old passwords for ever.

I'm thinking to set default maximum history count to 5 changes per entry, which could then be modified in Passy settings. It would not affect performance in any significant way, other than increasing save time by at most 100%. Currently, save time is pretty fast and, while I will have to investigate as to how much it gets affected, I believe it won't cause any noticeable save performance problems.

Consider, what if the device that runs passy, (ex smartphone) crashes/switches off due to no battery, mid-process, while one is changing password on one's laptop.

This is highly unlikely. Here is how the synchronization process goes:

1. Client checks if there are differences between itself and the server via hashing.
2. Client requests server entry synchronization history, compares it to local synchronization history and finds the differences.
3. Client sends newer local entries to the server as one message. The server receives client entries and then decodes and saves them.
4. Client requests newer remote entries from the server. The client receives server entries as one singular message and then decodes and saves them.
   Passy may fail to save/modify history during synchronization, in which case it will revert all changes to it. Passy may not fail to save entries and it happens very quickly.

have a concept of a new-edit-temporary-scratch-entry, that keeps data of an ongoing edit around until final confirmation

While this is definitely an interesting idea, I find this to be the most exhausting thing to implement in terms of UX. I don't see how it could be intuitive without previous guidance.

[hgkamath]

This is highly unlikely. Here is how the synchronization process goes:

[Edit] ignore this paragraph. I wrote it before I interpreted the above in the context of your history feature. -> [ The situation under consideration, corresponded to manual-workaround-4 in the issue description. It refers to a time during the "edit activity view" itself, where-in user has made a change in the field-text-box (ex-password), but not yet pressed the check/save button in the top right corner. The intention of the user being to have new password ready to save, not yet overwriting the old value. If smartphone turns off while on the edit page, the unsaved data in the fields are lost on reboot because they were intentionally not committed to the internal database and so outside the purview of synchronization. The user had not asked it to be saved and user was rely-ing on the edit being unsaved and cancel-able. ]

[Edit] then I reread your write-up, rgd the synchronization, the per-entry-history description and #9, and I think what you meant was if the history feature already existed and the user workflow relied on making the change boldly, saving it right away and relying on the history, then no data loss would happen, even during synchronization, because then all data would be committed to the database. -- ok

Thoughts on synchronization that you described:

• Synchronization happens periodically or by manual-trigger between a client and a server on agreed committed database states. I guess individual entries on both sides are timestamped by the savetime.
• If a user inadvertently edits the same entry on both sides, the more recent edit of the two will prevail.
• It is correct that if a user presses check/save, the save-entry operation should execute quickly in as short a time as possible for consistency.
• I guess there is a synchronization protocol password that is shared on both sides to ensure entries are sent over the channel are encrypted.

I'm thinking to set default maximum history count to 5 changes per entry,

per-entry-history sounds good if its easy and doable. Some history is better than no-history
With #9 the workflow for the user becomes, go ahead, edit entry, save, and user can always see history.
I had thought about per-entry-history and also per-field-history, but felt it has some lose ends, so I did not include per-entry-history or per-field-history in my enumeration. It also seemed over kill for the same reasons as before, as all one needs is the old-password and new-password for the duration of password change, until the password-change is successfully confirmed.
Aesthetic-changes and info-adding-changes happen sporadically in editing bursts.
Password-type fields are the only fields a user never re-edits for aesthetic reasons. A user changes a password when forced to change the password. The other fields, esp title, are often edited on a whim like to create a homogeneous listing appearance between similar entries (ex: email accounts).
Another issue here is that, a user never seldom gets all the edits right at one go. User discovers typo in name, discovers made wrong entry in website, etc, each time going back editing and saving.
These extraneous pushes onto the history-stack can cause the oldest history to be popped/lost, and that oldest one on the stack might be the one that had the needed older password.
Its for this reason I feel, if the user changes a hidden password-like field, then a mandatory history append is done. But if the user changes other fields, appending to history can be optional. The non-secret fields can always be gathered/recreated. It also true that these aesthetic-changes, info-changes happen usually on first creation. If the user is forever happy with them, then subsequently the only changes will be the password-changes.
One thought here is that a delete selected history entry would also be useful, in the event the user wants to remove an history-entry that just adds bloat to the history, in order to give a life-saver the history stack's tail end.
Well, maybe one could expect user to abide by the maxim 'Don't bother with aesthetic-changes and info-changes until the password change is successfully completed, or else you lose the history'

Other thoughts:

• I guess there must be a internal hidden GUID like unique ID per entry to uniquely identify an entry, as one cannot rely on any of the user entered fields to remain the same between edits. A user could change even the name, account-name and website field contents.
• If each entry has 5 older entries hanging around, it makes the saved data at-least 6 times as large, but a password database is small database.
• Perhaps the maximum history count could be configurable.
• What if history had time/age-based-expiration rather than history-count-based-expiration.? That would make the one less worried about history-stack popping out too soon.
• Would synchronization merge histories too? This would be more easier on time/age-based-expiration

Happy to be a sounding board if you need to bounce a thought.

most exhausting thing

It's a great thing you're doing.

[GleammerRay]

It refers to a time during the "edit activity view" itself, where-in user has made a change in the field-text-box

I see. I'll keep the draft feature in mind.

Password-type fields are the only fields a user never re-edits for aesthetic reasons.

It would indeed make sense to make the history feature only append when password and obscured fields are changed by default to avoid losing older history when it comes to password entries.

delete selected history entry would also be useful

Of course, entry history should be and will be modifiable by the user.

unique ID per entry

There is. You can have multiple entries with the same nickname exist at the same time. There is a near zero chance of collision as Passy uses UTC timestamps of entry creation dates as their keys. So, unless you create two passwords at the exact same millisecond, you will never ever experience an overwrite.

If each entry has 5 older entries hanging around, it makes the saved data at-least 6 times as large

This should not be a problem as:

1. Entry history will be saved in a different file, thus read speeds will not be affected.
2. There will not be any synchronization for entry history. At the moment it seems like a bad idea, as storing it locally feels sufficient, but I might add an option for that to occur if specifically requested.

maximum history count could be configurable

Of course, the default of 5 seems sensible for most users but some might want to increase the count or disable the feature entirely to improve write speeds on slower hardware.

What if history had time/age-based-expiration rather than history-count-based-expiration.?

It would be a great idea if this feature is to track all changes. However if it only tracks password/obscured fields it doesn't make much sense.

Would synchronization merge histories too?

As mentioned above, I'm not planning to facilitate this yet. If I was to implement synchronization for it, best option would be to merge all and remove the oldest on next push. Adding extra logic into synchronization is never a good idea as it will affect the synchronization speed.

Happy to be a sounding board if you need bounce an thought.

Oh absolutely. Thank you so much for your input! ❤️