Password content data loss bug in 4.0.9
To reproduce:
- Edit a login with an existing password.
- Generate a new password by clicking on the password field and changing the pasword length slider.
- Click "Cancel" to stop editing. When prompted click "Don't Save".
- The password field for this login appears to now contains the new, unsaved password. If you view or copy the password you'll have the wrong (unsaved) content.
- Browser fill also appears to use the unsaved password.
- Old password does not appear in history.
- The unsaved password does not appear to be written to the backing store, quitting and reopening provides the original password.
Depending on what you're expecting to happen this sequence can easily lead to loss of the password. I copied what I expected to be the "old" password into the wrong field on a password change page and ended up changing my site password to one that was unsaved. I ended up needing a password reset from the site.
Finally, its worth mentioning that your restore from backup functionality is misleading. It claims a new backup will be made before the restore, but it appears this only happens if there has been a change. Since my backing store was unchanged (I didn't realize this at the time), I was confused that no new backup was created (potentially losing my only clean copy of the "unsaved" password). I ended up restoring from real backup tools. Restore should always produce a new checkpoint, even if you think the data is unchanged.
Comments
-
Hi, @Axel. Thanks for reporting these issues.
The first is resolved in 4.1.BETA-4, mentioned in 1Password 4 for Mac Release Notes with Show Betas enabled:
- Fixed problem when the view was not reloading after not saving an edited item.
The second about 1Password failing to unconditionally do a backup before a restore is already in our bug tracker and I've noted your comments about it.
I hope that's helpful.
0
