1Password Losing Passwords
I've had this happen to me three times... first two times I thought it was me, second time, I think there's a nasty edge case. I'm intending on conducting more experiments, but has anyone else seen this behavior:
The use case is that you're trying to change your password on a site. Let's say LiveJournal.
You go to the site, get to the point where you are prompted for your old and new password, so you fire up 1Password, bring up the record, copy'n'paste the old password into the web form. Then you see all the criteria (length, character sets, etc.) and so you press Edit on the 1Password record, go to the Password field and have it generate you a password with the desired criteria. You copy that into your clipboard buffer, press Save (and at this point you're looking at a normal 1Password opaqued page again), and you paste the new generated password into both new password fields. Press submit, and you get a happy message the password has been changed to the random block of bytes.
But just as you're hitting submit, a dialog from 1Password's browser extension pops up and says do you want to Update the Existing Record. Sure, why the hell not... you click it, all looks well.
...but then you go back to the 1Password record, press Option to reveal it for the moment, and what do you see? The original old password? (PANIC ENSUES)
If you are fortunate to have the password still in your clipboard, as I was because the times I got locked out and had to issue a password reset right after changing my password has made me super gun shy, then you can recover by re-editing the record and verifying it.
But, if you've done -anything- to alter your clipboard, you're hosed. The website knows your new password, but 1Password does not.
Now, as I write this, it may not be as completely bad as I had imagined... the Previously Used Passwords may still have it in its history. In my case, it did -for web pages-. But services, like Wickr Me, which I entered from the iPhone, no such luck.
( I'm going to try to make a screen cast of this happening at some point, if it keeps doing it. )
1Password Version: 6.3.3 (633001)
Extension Version: 4.5.8
OS Version: OS X 10.11.6
Sync Type: Dropbox
Comments
-
1PW should deal with this case, but the approach you have used is an error by the user.
When the password is generated, DO NOT save and paste it. Just apply the Fill option, and it will fill the new password and save that password in the Passwords section. You may have to do some work to convert it to a login, but that way the password never gets lost.
0 -
Hi @wls,
I'm sorry you've encountered such an odd problem when trying to change a password for a website & Login item!
If I understand your description, it sounds like you're clicking the Edit button for the Login item and using the button next to the password field to generate a new password. If so, danco's suggestion above might seem confusing to you at first because it's actually referring to the "preferred" method of changing a website/Login password. We explain that method here: Change your passwords and make them stronger
Although the steps you've been using shouldn't cause a problem like the one you described, I think the steps in the above knowledgebase article will be better for you for several reasons. The first is that, when using the Password Generator option in 1Password mini / browser extension, a record of the new generated password will be saved in your vault as soon as you click the 'Fill' or 'Copy' button (which is what danco was referring to). So even if something goes wrong and your Login item isn't updated with the new password, you'll be able to find it (so you won't have to worry about whether it is still saved in the clipboard).
Another benefit when using 1Password mini > Password Generator is that you won't need to go into Edit mode for the Login item. Once you submit the 'change password' form on the website, 1Password should prompt you to update the existing Login item with the new password (and of course it should work as expected). That'll save you a few steps because you won't need to make any edits yourself.
Also, not all sites show you their criteria for new passwords, so you might generate one that isn't accepted by the website. That might be a bit confusing if you've already saved that new password in your Login item. Instead, when you use the method from our knowledgebase, you can submit the new password without changing the old one. When 1Password asks if you want to update your existing Login with the new password, you can wait to see if the website accepts it first.
I hope this helps! Again, the problem you described shouldn't happen, but if you follow our steps for changing a password, you won't need to worry about that issue possibly happening again. If you have more questions about that, please let us know. Cheers! :)
0 -
FYI, having worked in QA, I have no problem with folks telling me the problem is between my chair and keyboard.
So, let's address Danco's comments first. I recognize I should do a save'n'fill, though some web pages in the past don't have their password fields set up quite right, and I've gotten burned. (Password pasted in a public field, the page getting one password field but not the verify, or worse the page getting submitted and then I have to fight email delays to get another reset token. None of this, however, is 1Password's fault -- it just means I play things extra cautious, because I have had changes not retain in the vault.)
Now, over to Drew_AG's comments; this time I'll put on my Developer-hat. What it feels like is that 1Password-mini has its own cached version of the website's old password and when it writes to the vault, it steps over the password I just changed. Or, conversely, it's not detecting a change -- perhaps the password I've typed is the same as it has, so it just re-write a previously cached record in full out in hopes of updating a time stamp.
If I wanted to deliberately induce such a bug (such mental exercises exist to deduce strange paths), I'd detect a password field going in transit and make the offer to save, but I wouldn't pull the value from the form, rather assume that someone had properly used the fill function and the actual password is in a 1Password buffer ...perhaps the very one that might be used to authenticate the site. That might account for an old cache getting written back to disk.
Note, If I have the changed password still in my clipboard and notice that it's happened, I can "repair" the problem by re-editing the record. ...although that's not the point; I shouldn't have to. However, I've also learned another work around is to not accept the offer to Update the Existing Record after the browser moves on to the next page. The saved record with the new password remains untouched.
That said, looking at the link you passed, I can concur that this is not how I'm currently doing it -- primarily because I ended up with lots of password cruft a while back. But I think you and Danco are right that this is the "correct" way to go about doing it.
And, yes, I'll be adopting that behavior.
However, I think that I may have exposed an edge-case bug in 1Password. In theory at least, and I'll hope you'll grant me this, that if I change and save a record in 1Password, and then filling in a form with the identical information that's in that newly saved record, nothing should revert the record to the previous password value when pressing Update Existing.
( e.g. the password is AAA, change it to BBB, save form; then type BBB in web form, accept Update the Existing Record, this should not put the password in the record back to AAA. )
I'm of the opinion that software should operating with a rule of no-surprises, rather than requiring a user to alter behavior to get a desired result. But I think it's fair to say at this point, I owe you all a screencast of this actually happening, because even as I read this, even I wouldn't believe it so. I'll be the first to admit that it does sound like the more likely case is it really is a user error, although I took these steps slowly and carefully before posting. Still, mistakes can be made.
But in the meanwhile, thanks for pointing me on a better path.
0 -
Hi @wls,
Thank you very much for your thoughts & additional details about this! I hope you don't mind, but I've moved this thread to our "Saving and Filling in Browsers" forum.
After reading your message (and re-reading your original description of the problem), I have a theory about what happened. When you edit the Login item and generate a new password, it sounds like you save those changes before submitting the 'change password' form on the website. So, when you submit the form, 1Password shouldn't actually prompt you to update the Login with the new password, because the new password is already saved in that Login.
However, you said it prompts you to update the Login anyway. When you submit the 'change password' form, 1Password looks through that form for password fields, so it should detect the two different passwords you've entered. Now, I'm not a developer, but my guess is that 1Password compares them to your Login item, sees that one of the passwords in that form matches the one in your Login item, and therefore deduces that the other password in the form is the "new" one - but in reality, the one that doesn't match your Login item is your old password. When it asks if you want to update your Login item with the "new" password and you accept, it replaces the new password in your Login item with the old password from the web form (because it thinks it's actually the "new" password).
Again, I'm not a developer so I don't know for sure if that's the logic 1Password is using at that point. But if it is, that would certainly seem to explain why it replaces the new password with your previous one. Essentially, you're editing the Login item twice: The first time is when you manually edit the Login, replace the old password with a new password, and click Save. The second time is when you submit the 'change password' form on the website and accept the 1Password prompt to update the Login item with the "new" password from the form you just submitted.
Like I said, that's just my theory of what might be happening. But even if that explains why that happens, you're right that it's not necessarily the expected behavior, and hopefully we can improve that in the future. I'll let our developers know about this. In the meantime, if you follow the steps in this article to change a password, that should work properly and avoid confusion about which password is the "new" one, so the Login item is updated correctly.
Thanks again for your thoughts about this, and please let us know if you need anything else! :)
0 -
@Drew_AG, I think you nailed what's happening -- or have at least proposed a viable theory!
Usually there's a good rule of thumb that if one user is doing something slightly different, there's a whole subpopulation doing the same thing.
And, while I can change my behavior and also do workarounds, the longer-term goal I'd figure is to have the software not allow such a problem to happen by either not letting the user go down that path or by doing something reasonable, expected, or easily explainable.
I'm going to fiddle with it more and see if I can get a trivial case that repeats the problem and then provide the exact steps and/or a screencast of it happening.
0 -
You may be right. Please let us know what you find!
0
