My biggest problem with this functionality was my lack of trust it had been updated properly. It heavily relies on correct field names/mappings. When I was using Lastpass I would open details and check manually each time, especially for services where losing password would mean loss of access to service/website.
I would prefer if popup contained essential details about updated fields, allowing you to accept, not accept or ‘edit before saving’ (if any data changed was captured incorrectly). I’m not sure if this is a security risk though.
An option to show basic popup or more detailed popup would be nice to have.
An option to disable automatic change detection (so it’s not annoying) would be nice to have.
@eskela@K0media For my money, any automatic detection is just too risky. The only solution to this problem is password history (when password changes, old password is automatically saved to history). There’s just too many ways for an automated procedure to fail (connection to website times out or you lose internet; who knows whether the submitted password update succeeded or not? What if the new password has the wrong special characters? What if they updated their password field to have wonky attributes and Bitwarden can’t detect that the password was updated?)
I am also concerned about an automatic detection of a password change failing. I gave up on LastPass because of this problem. I was forever having to clean up after a password change, because LastPass mishandled it.
The Password Change process usually requires providing the existing password and a new password. Using the BitWarden’s Password Generator function will overcome a user’s reluctance to creating new passwords (usually because they can’t think of anything!!!).
As things are currently implemented, using the Password Generator results in losing the current password of the account. Remembering this existing password is important if the password update process fails.
Any improvement to the process needs to keep both the existing and the newly-generated passwords until the update process is completed successfully.
What I did was create a Custom Field, called Old Password, as I was processing the Password change. That way, I could recover if the password change failed.
Keeping old passwords in the BitWarden database would not be a security risk, but may have to be limited by database size constraints.
I’ve actually lost the root password to my server once because last-pass didn’t update my password properly. It wasn’t fun spending the whole next day reconfiguring my server from scratch, restoring backups, etc.
EDIT: Not to mention any data loss since the last backup, which would be about 12AM the day prior.
EDIT2: @redquinoa is spot on with password history.
I’ve definitely had passwords update in LastPass but fail to update on the site for a variety of reasons - including “password too long”(!) and connectivity/server issues. For services that require the old password to update to a new one, this can be quite a problem.
However, more common was that LastPass failed to detect a password change, even after using its generate+populate password feature. My normal workflow was to copy the password before hitting submit so that I could edit manually if needed.
This is non-trivial to detect in all cases, particularly for single page apps - like Discourse here which neither LastPass nor Bitwarden handle successfully.
Agreed. I almost lost a password when trying to update a login. The edit function overwrites the old password and if the website doesn’t accept the new one you are hosed. Currently I have to copy paste the new password into an editor until I’m sure the new one is accepted.
This would be great, but it never worked well on Lastpass, I was never sure if it had saved the suggested new password or not. Sometimes I ended up re-resetting the password because something went wrong.
Detecting password changes is tricky. Also in 1Password one has to manually verify changes. Even just storing passwords has to be checked manually as field mappings just aren’t always perfect, understandably.
However, when a password is changed I expect Bitwarden to provide me a prompt to update my vault, preselecting a login but allowing me to select another login or create an entirely new one (on some sites I have multiple accounts, for instance a user account, a ‘john doe’ account and an admin account).
Detecting password changes and storing them requires the password-changes to be stored properly. That’s not implemented in Bitwarden yet (see this feature request ). When something went wrong with a password change while the new password got stored anyway, it should be possible to get back to the previous one easily.
I just cannot justify migration from 1Password to Bitwarden while these two issues aren’t resolved. I’m in no hurry of leaving 1Password as yet, at least not until I am forced to comply with their new and expensive licensing structure. 1 vote for me on this matter.
This is my first post so it may have some newbie anomalies
Password history will improve the update password process but because this is a fundamental function it should be way easier than it is. A variation (or an addition to) password history is to add a New Password box with three actions:
Generate Generates a new password
Copy Copies the new password to the clipboard
Update Copies the new password to the current password
The box could go on the view screen or a new Change Password screen that includes the Current Password box.
It woud be good if the Update icon was red when New Password and Current Password are the same and green when they aren’t
Also, if the right click on the site could include Copy New Password and Copy Current Password
p.s. an eye to view the new password should be a forth icon. And the generate and copy function could be combined
Detecting password changes has been added to the browser extension for the next version (1.29). It works like this:
If Bitwarden detects a form with exactly 3 password fields on it, we begin to monitor it for submission. If that form is submitted and two of the password fields contain the same value (new password), and the one other field (current password) matches the password for one and only one login in your vault for that website, we then present the “changed password notification” which will update the new password for that login item.
Obviously there are edge cases with some websites that will not meet this strict criteria, but we have to be careful about presenting this notification to users and I think this covers the majority of the use-cases.
We also now have password history starting in 1.29 that can allow a user to recover a lost password if a change password update happens for some incorrect reason and overwrites an existing password.