I strongly agree with this. The password should only be saved to the history if and when a user either clicks Select or Copy Password, not every time that the generator page is visited or refreshed!
3 Likes
Thanks for the tip.
How many days of history are kept?
This feels too close to this discussion to be a separate enhancement request, but I as a user I really want reassurance that my nice secure random password isn’t going to get “lost” in the time between when submit it on a web page and when it’s saved (and synced) in my password manager.
I had imagined implementing this as a kind of persistent record where a newly-generated password is saved any time it’s “released” into potential use, and from which the password is deleted only after that password is saved in a “normal” password record, or with explicit user confirmation (or following some other user-selected policy). Conceptually, it’s a little like a write-ahead log.
So, a password might be saved to the log when it’s (e.g.)
- Copied to clipboard
- Filled into web page field
- Displayed in cleartext to the user (probably?)
Saving a new item (with a password field) or editing an existing pass item’s password field would trigger a check of the log, and the matching password would be deleted after the main database write has completed. (This is 99.9% here to protect against the case where there’s no attempt to save it at all, but might as well also cover the 0.1% where the save fails).
If a password in the log isn’t saved to a real record:
- It should be retained until there’s a clear OK from the user to delete it, and
- There should be some UI method of informing the user (within a timeframe and context that gives them some chance of knowing what’s going on) that a password was generated and (potentially) used but not saved, and giving them tools to either save it or confirm that it should be deleted.
I would add that storing a large or infinite history of generated passwords doesn’t fully provide this: Especially when many systems penalize wrong guesses, getting a list of 500 semi-recently-generated passwords and knowing that somewhere amongst them is the correct one is only barely better than it just being gone. I think relatively-timely interaction with the user, while they still know what the generated password was for and whether or not they actually used it, is important, and retaining some context information (what client was being used? For a browser extension, what was the URL? Was the user creating or editing a record, and if so which one?) might be as well.
1 Like
In most cases, feature requests tend to take quite a while to get implemented, even after they have made it onto the Roadmap (which the present feature request has not, nearly five years after the original suggestion was posted). Thus, for anybody who is still having issues with “lost” passwords, I would strongly recommend that you adopt/adapt the approach that had been suggested by David H above, since this method will guarantee that you never lose another password. I personally use the following variation of the method described previously:
-
Disable Ask to add login.
-
When you’re on a website’s account registration screen, before typing anything into the web form, open the Bitwarden browser extension — all of the steps below (except the last one) are performed in the browser extension.
-
Click Add a login or
, which opens the vault item creation form and prefills the correct URL. -
Enter the desired username in the username field, and click the generate button (
) in the password field, which takes you to the password generator. -
Click the “Select” button (top right) in the password generator, which transfers the generated password to the login item.
-
Click the “Save” button (top right) to save the newly created login item — because the password is now saved in the vault, it is impossible to lose it.
-
Scroll down and click the Auto-fill button, which will transfer the username and password from the vault to the website’s account creation form.
-
Submit the account creation form.
The above may not be what you’re used to, but it is the same amount of work (or less) than using the auto-save (Ask to save login) feature, and it prevents password loss 100% of the time. Thus, if you’re currently frustrated by loss of passwords due to failed auto-save attempts, you might as well give this approach a try while you’re waiting for Bitwarden to improve the robustness of their auto-save algorithms.
This is exactly what I came here to ask about.
Lastpass failed me in this regard, and at the time I simply could not believe that a password manager could be so careless with persisting its users’ data even when it suggested that data itself.
It’s very disheartening to hear that there seems to be no proper persistence strategy here in Bitwarden either. Hearing this as a new user (as of today), I’m immediately filled with doubt about choosing this as an alternative to Lastpass — I simply need to know that the developers of the security product I use understand these things. You must persist generated passwords before releasing them to the application/user. Doing anything else is basically relying on that the detection of signup/password changes is 100% accurate, which is absurd, and, if this thread is to believed, far from reality.
Password suggestions are simply not safe if this is not done properly.