Updating a Logins password can overwritten
I am attempting to update multiple passwords on multiple websites. Using the desktop app I'm editing the Login entry for a website, generating a new password in the desktop app, saving the entry, and copying the new password. I'm then using Google Chrome and going to the website, logging in and updating my password with the one generated from and saved in the desktop app already.
Upon submitting the password update I get a 1Password window asking me if I want to Update Existing and if I choose to update, it replaces the newly generated/saved password with the old password I'm trying changing. If I repeat these steps but choose not to Update Existing then the expected password (newly generated) remains.
My expectation is that 1Password either doesn't prompt me to Update Existing as the password I just created and saved and the password I'm updating to on the website are the same. If that isn't possible I'd expect if Update Existing was clicked the the same password would just be updated with itself but never the old password.
STR:
- launch 1Password desktop app
- edit a saved login for a website and use the password button to generate a new password
- save this login entry and copy the newly generated and saved password
- launch Google Chrome (64.0.3282.167) desktop app
- go to the website you've just changed the password for in the desktop app and change your password
- 1password window will ask if you want to update your password and you accept
- looking at the password via the extension or desktop app and it's the old password you just changed, not the newly generated password you saved in the desktop app and used to update the website with
Thank you.
1Password Version: 1Password 6 Version 6.8.7 (687006) AgileBits Store
Extension Version: 4.6.12.90
OS Version: 10.12.6
Sync Type: Dropbox
Comments
-
I am attempting to update multiple passwords on multiple websites. Using the desktop app I'm editing the Login entry for a website, generating a new password in the desktop app, saving the entry, and copying the new password. I'm then using Google Chrome and going to the website, logging in and updating my password with the one generated from and saved in the desktop app already.
@sdotm: I'd really recommend doing it the other way around — on the website first — since you will need the current password first to login (and often during the password change process). There's no way to fill from password history. We have a great guide for this that might help:
Change your passwords and make them stronger
Upon submitting the password update I get a 1Password window asking me if I want to Update Existing and if I choose to update, it replaces the newly generated/saved password with the old password I'm trying changing. If I repeat these steps but choose not to Update Existing then the expected password (newly generated) remains.
Right. 1Password has no way of knowing what you're doing and why you're doing it, so it can only see that you're using a different password on the website than the one it has saved, and the vast majority of the time users will want 1Password to save it in that case. You can, however, easily dismiss the autosave prompt and continue if you like.
My expectation is that 1Password either doesn't prompt me to Update Existing as the password I just created and saved and the password I'm updating to on the website are the same. If that isn't possible I'd expect if Update Existing was clicked the the same password would just be updated with itself but never the old password.
This isn't a bug, but working exactly as designed (which is nice to hear since 1Password isn't perfect and doesn't always offer to save/update). To be clear, 1Password isn't overwriting passwords automatically without your consent; it only saves it if you tell it to do so.
Hopefully my explanation above helps make that clear, but if you have any questions please let me know. Ultimately we recommend doing it that way because a password you generate may not meet the website's requirements if you're doing it in a vacuum, so you'll only find out it doesn't work when going there. Also, there's an important safety net in place in case you run into an issue with this: a Password item will be saved in your vault when you use a generated password on a website. Cheers! :)
0 -
Hi, thanks for your feedback.
I'm not sure I believe this is how 1Password is expected to work. It is an issue that I can overwrite an existing password with an old password. I've already given 1Password the new password so at least it should recognize the password I'm updating on the website is in fact the same password living in 1Password and not prompt to have me update my password. The fact that it knows I'm changing my password and is storing the wrong password during that change is something I'd consider a bug.
I'll re-evaluate my workflow to changing passwords or look into alternative solutions to 1Password.
0 -
I'm not sure I believe this is how 1Password is expected to work.
I'm not sure what to say to that. The only two ways I can read that would be either that you're suggesting brenty doesn't know how the software he provides technical and customer support for every working day is actually supposed to function, or that he's not telling you the truth about it, for some reason.
Neither is true.
This is indeed the way 1Password is supposed to function: if a set of credentials is entered into a website for which a user already has one or more saved login items, 1Password will detect the entry and offer a choice of 1) saving it as a new item (in case the user has multiple logins at the same website) OR 2) making changes to an existing item. The third option in such cases is of course 3) cancel.
I'll re-evaluate my workflow to changing passwords
That's definitely going to be the easiest solution: 1Password is designed so you can visit a website at which you have an account, use auto-fill to sign into your account there, proceed to their "change password" page, use 1Password's password generator to create a new, unique, strong password, then - when you click "save" or "enter" or whatever, 1Password will offer to save the changes as an alteration of the existing Login item in its database.
There's no need to open 1Password, find your login item, use the password generator to change the password within 1Password but not at your actual account, then visit the website, login with the OLD password (which would mean you have to not use 1Password to help you sign in, but instead manually type in your old password) click "cancel" on the offer to save changes, find the site's change password page, manually copy and paste in the new password you created, click save and again click "cancel" on 1Password's offer to save because you already entered it manually earlier.
Let us know if you have any questions about the process, or refer to that link above; it walks you through the steps to change a password. Have a great weekend!
0 -
Hi, thanks for your feedback.
"Don't hold it that way" isn't really the response I was hoping for...
If you genuinely feel that a user telling you there's a way to unintentionally overwrite a password is not an issue, at worst a bug, at best poor UX that could be looked into and improved, then I don't know what to tell you.
I'm aware of my options and I'll take it from here.
Cheers.
0 -
@sdotm - so I did a little more testing, and it looks like you may be right - if you do it the way you suggest, 1Password for Mac does appear to save the incorrect older password as the correct password when you've already changed it in the app itself and are offered the chance to save it again because of the changed values for password. You can cancel out of this by clicking "Not Now," but 1Password certainly should be saving the correct value for the password.
We'll look into what the saving logic is there, and likely be filing an internal bug report for the issue, but for your current endeavor, I'd like to suggest that you use the method that both brenty and I linked to for changing passwords -- change them on the site itself and allow 1Password to save the changes, instead of changing them within the app and then doing the actual changing on the website in retrospect. It's considerably fewer steps for you, and we know it works the way it's intended. Thanks for reporting!
0 -
"Don't hold it that way" isn't really the response I was hoping for...
@sdotm: You're the only one saying that. I hope you can see from my reply above that I'm not saying "you're doing it wrong" or proscribing that you do it "my way", end of discussion. Rather, I try to lay out why 1Password is designed this way, which is ultimately to help people secure their accounts without locking themselves out too. I apologize if I failed in that regard and didn't communicate as well as I should have.
I get where you're coming from, and you're not wrong. Changing back to an old password is a terrible idea and not something we'd ever recommend. But at the same time, some people do this. And it's 1Password's job to 1) offer to save passwords whenever possible and 2) do so when the user tells it to. I don't like the idea of people reusing passwords (again, not suggesting that's what your'e trying to do, but the effect is the same as far as 1Password is concerned), but I think we can all agree that getting locked out of an account because 1Password doesn't properly save is worse.
So I have to disagree with Lars too here, as changing this behaviour could result in data loss. That said, I agree with you that in the particular scenario you've created, it can have less desirable results. But we have to consider all users as best we can when designing this stuff. It's definitely a discussion worth having though, and I may be proven wrong or just overruled, but that's my take.
0 -
@sdotm - so, I managed to grab a little time with one of the extension developers this morning, and here's the low-down. I have to confess I was a little blindsided by this because it never even occurred to me to change passwords the way you do it -- it requires a few more steps than the way we designed 1Password to change a user’s passwords, and it's overall a more-clunky and cumbersome way to do it, in my own opinion. But you were correct that 1Password appears to be doing the wrong thing by offering to save the older password that you just changed (manually) and discarding the new one.
What I had even more trouble figuring out was that in both your scenario AND the one we've been telling people for years to use when changing passwords, the actual data in the input fields is exactly the same:
Field #1:
current password:(the "old" password for the site)
Field #2:new password:(the newly-generated password...whether it was just generated on the page, or was created and saved earlier by the user in 1Password)
Field #3:confirm new password:(same)So here's the story. Since, in both your case and our "official" case the fields and the actual data in those fields are identical, why does the 1Password prompt in the official method save the "new" (generated) password correctly out of that input, while doing it your way results in saving the OLD password as the current one, overwriting the new one you generated and saved previously?
Here's the logic: although everything on those two pages (one done "our" way and one done "your" way) is the same, what's not the same is what 1Password already knows or doesn't know about what the user is doing, and what 1Password does is not determined solely by what's on the actual page. When you change passwords the way we suggest, 1Password looks at the current password in its database and determines that it matches it with the "old" password on the page, and therefore concludes that the new one it just generated must be what you're trying to change TO, so it offers to save the new one as the correct "new" password. In other words, the current password is XXXX, so you must want to be changing to YYYY. In your case, 1Password also looks at its database, only this time what it finds is that the "current" password in the saved Login item is the one you generated and saved. In other words, even though YOU know that's the new password you're trying to save, 1Password sees that it's already the current (XXXX), so therefore using the exact same logic it concludes that the only other password on the page, (the "old" one), must be the password you want to change to (YYYY).
Why can't 1Password recognize that it has that password (YYYY) already in the list of previously used passwords? It can and could. But as brenty said, above, although we certainly think reverting to a previous password is a bad idea in most circumstances, there could be instances where it would be either desirable or necessary, and we don't want to prevent the user from changing to what they want. Remember, the only reason 1Password thinks the user might want to (re)save that older password is because it's checked its own database and found that the "new" password - the generated one that you're actually trying to save - IS the "current" password already, at least within 1Password itself.
It's an interesting problem, but one that easily solved or worked around in practice by either:
- Changing the passwords at sites in the way we've been recommending for years, or
- Clicking on "Not Now" when 1Password offers to save the password, if you are doing it this way.
Finally, if you actually do click Update and the old (existing) password is saved, the new (generated) one that was overwritten by 1Password's logic when you clicked Update Existing will still be available in the password history of the Login item in question, so you won't ever be locked out of any site.
Could we change how 1Password operates to avoid you having to do this? Yes. Will we? I seriously doubt it, because to prevent the potential of an overwritten password that can arise from the combination of the specific, contrary-to-instructions way that's required to get to this possibility, we'd have to either not offer to save/update (which is a non-starter) or we'd have to change the behavior of how 1Password determines what to save. Would it be possible to write checks for this that could reliably offer to save the correct password when done this way? Maybe. But here's where we get into the other considerations that go into what to spend time on. Since we've given out the same instructions for how to change passwords for years now consistently, do we want to spend developer-cycles attempting to write additional code (and make sure it doesn't cause unforeseen secondary effects or false negatives to other users), to prevent someone from saving a login in a way we don't recommend? I don't know -- maybe when don't have other priorities competing for our developers' time -- but for now, we recommend you either don't change passwords this way and instead use the preferred method, or you make sure to click "Not Now" when 1Password offers to save (because you already saved it yourself). Thanks for the lively discussion, and have a great rest of your weekend. :)
0
