Server: protect users from generating then losing passwords

[nilsbecker]

i'm gonna make a seemingly bold claim:

"every password generated and not stored puts user accounts at risk"

what i mean is this: using the password generator it's easy to generate a password, copy it to the clipboard, set a new password for some account on the web to that generated password, and then lose the password -- it was only ever present in the system clipboard. of course it's a user error, but this is annoying enough that it should be prevented as much as possible from happening.

what makes it worse is that in the 'create new login' panel one can choose to generate a password, but then one has to press the 'save' button to actually save the login with the generated password. this is easy to overlook: copy and paste the generated password, confirm new password on the web page; a new page loads and the bitwarden panel disappears - password lost except in the system clipboard.

i think bitwarden should find a way to avoid these user error traps. for instance, all generated and then clipboard-exported passwords could be saved in a 'password history' just so the user can try out the last ones when he realizes his mistake. this could be a rolling list limited to 100 entries or less.

[kspearrin]

One problem here is that doing something like moving the length slider (browser/mobile) causes a lot of passwords to be generated which may quickly fill up the history buffer.

[nilsbecker]

true. as a remedy, i would suggest only saving those passwords that actually get used in some way.

i.e. passwords that either get copied to the clipboard or get accepted for a new / edited site login (before saving the login, since then the password is 'safe' anyway)

as a further enhancement, letting each saved site store a password history of its saved passwords might be interesting as well. but i think that one is less urgent.

[dabura667]

This is good. There could be a few triggers that would cause a history entry:

1. The user leaves one password displayed for more than 10 seconds without performing an action or exiting the generator. (They could be manually writing it down or typing it into a separate notepad app etc) (You could reset the 10 second timer every time a new password is generated (while moving the slider etc.))
2. The user clicks the password text element. (Assume that clicking is an attempt to select the text for an eventual Ctrl + C.
3. The user clicks the copy password button (obviously)

And since a user could leave it open, then click it, then click the button, the history queue should not add the password to the history if it already exists in the history. Or if it is the most recent entry (I highly doubt the password generator would generate the same password twice, so this condition seems fine)

[nilsbecker]

i agree that there should be a clear story for when a generated password is 'safeguarded' i.e. stored in the history.

while it's good to catch many occasions it's also important to keep the history relatively small, since recovering a password from that history is always going to be a trial-and-error process to some degree. it's a last resort.

so i'm actually doubtful about 1.: manually noting down means there is a safe copy, and manually typing into another application should not be encouraged as it is error prone and the wrong way. so deliberately not doing 1. would make sense to me.

for 2, this would make sense if detecting actual ctrl-c (i mean, the event of copying to the system clipboard) is not feasible.
alternatively, it would also be a consistent story if clicking the button (i.e. 3.) is the _only_ safeguarded way. there could be even a little visual cue 'password recorded' or something that appears whenever clicking the button.

so i'm on the fence about 2.: if ctrl-c is not directly detectable it would make sense to deliberately only support 3.

[5nafu]

Lastpass has exactly this behavior and it bugs me more often than not.
I have to regularly clear out Password without category because Lastpass stores (safeguards) the generated password and then stores the credentials for the page separately.

Additionally, if you are not careful, you might end up saving the password but forgetting to safe the username. If the username is simple (because you always use this, or it is your email address), it is not that bad. But Murphy will call. :-)

Last but not least: Who says that I generate a password for the page I am on? I personally quite often generate passwords for databases or user accounts which will _not_ be stored in bitwarden. If the current page already is in my store, and the safeguard overwrites my current password, "to prevent me from losing it", it will exactly do that.

[nilsbecker]

If the current page already is in my store, and the safeguard overwrites my current password, "to prevent me from losing it", it will exactly do that.

i agree that this should not happe. current site passwords should of course never be overwritten by new passwords generated by clicking on 'generate password' automatically. the only time when a site password should be overwritten is when you save the new updated site login. the 'password history' we are discussing is separate from the password stored for a site login.

incidentally, lastpass has a password history per site. another useful safeguard mechanism, however that one is (a) different from the 'history of generated passwords' in that it does not safeguard against losing generated but not saved-for-a-login passwords, and (b) adds more complexity.

[kspearrin]

This is now available in desktop and browser apps.

[nhoad]

I was just bitten by the lack of this feature on mobile, and as a result I'm locked out of my banking app. Please consider implementing this for the mobile apps as well.

[CanisLupus]

I just discovered that Bitwarden mobile doesn't save my generated passwords so I was also locked out of an account for which "recover my password" is not working (I've sent them an email in the meantime).

I think this would be really important for mobile.

I actually had started a secure note with the password already pasted (hadn't saved yet), but I switched apps and by the time I returned (probably hours later), the note was gone. Android could have killed the app. An auto save of secure notes on "app focus lost" could be a useful too.

[dabura667]

iirc mobile is being totally rewritten, so it's falling behind on features while it is rewritten to use more common libraries with the other clients.

Just a little longer, methinks. Meanwhile, mobile is a tad nerfed.

[CanisLupus]

I see... That is good to know!