Update saved password algorithm should have more smarts

asbjornu

1Password has a feature that detects when a password has changed from the one that it has saved for a specific web site. This is great. But sometimes, it's a bit too eager to suggest replacing the saved password, which is annoying. Here's a couple of suggestions to improve the algorithm:

1. When websites have three password fields in a submitted form and two of them have the same content, you can be pretty sure that the repeated password is the new one, so don't suggest saving the one that only occurs once. This is true for Last.fm's Change Password form, for instance.
2. When the submitted password is one of the previously saved passwords, it's pretty safe to say that it was entered into a "current password" field and not something a recently generated password should be replaced with.

The reason I make these suggestions is that I just logged in to Last.fm's website to change my account password there due to the Last.fm account breach. Perhaps my procedure for changing password on a website is sub-optimal, but it works for me and I don't see why it shouldn't be supported. What I did was:

1. Logged in to Last.fm.
2. Found the "Change Password" form.
3. Copied my current password from 1Password and pasted it into the "Current password" field.
4. Edited the Last.fm login entry in 1Password, generated a new password, clicked save and then copy to have the new password in my clipboard.
5. Pasted in the new password in the "New password" and "Confirm new password" fields.
6. Clicked the "Change password" button.

What then happened was that 1Password asked if I wanted to update the saved password. I clicked "Update" and 1Password then saved the "Current password" (i.e. the old one) from the submitted form as my new password for Last.fm, effectively erasing my generated password. Thankfully, 1Password has a "show previously used passwords" feature, so I got my new password back, but it would be nice if the update saved password detection algorithm was a bit smarter so it didn't suggest updating the saved password in this situation.

---

1Password Version: 6.5.BETA-18
Extension Version: Not Provided
OS Version: OS X 10.11.6
Sync Type: iCloud

littlebobbytables

Greetings @asbjornu,

We'll certainly take a look but what surprises me is we already do that when it comes to forms with three password fields. It seems easy enough to create a test account for Last.fm so we should be able to poke and prod and figure out what is happening.

I just have one question regarding the steps you outlined. If you manually edited the Login item, changing the stored password to the new one prior to submitting the change password form why would you need 1Password to update a Login? When we go to test the site the one thing we'll be doing differently is after your step 3. we'll use the Password Generator available in the 1Password mini menu to fill the remaining password fields with a newly generated password. When we do this 1Password creates a Password item with that generated password as a safety net, storing the URL of the page given this happened in a browser. 1Password will ask if you want to update and should it find the new password is stored in a Password item for the same site it removes that item, the idea being it has served its purpose. This small change in the steps shouldn't alter how 1Password behaves but it should feel that it flows a little nicer and also won't expand a Login item's password history should you find you have to use trial and error to discover a site's password restrictions (I've suffered this once or twice).

We'll report back once we learn a bit more about their password change form.

littlebobbytables

Hi @asbjornu,

So I've created a test account at Last.fm and went through the steps I would normally use.

1. Visit the change password form.
2. Copy the current password into the correct field.
3. Use the Password Generator to fill in the empty password fields.
4. Confirm password change.

1Password prompted me as it did with you and it updated the Login item correctly as the first thing I did afterwards was log out and log back in. I'll next see what happens if I try the steps you detailed. The initial test seems to indicate it's working as expected though. Of course it might just mean there is a subtle bug to locate.

asbjornu

@littlebobbytables First things first: I love your nickname! :smile: Now on to your question:

If you manually edited the Login item, changing the stored password to the new one prior to submitting the change password form why would you need 1Password to update a Login?

I don't. But I'm an easily distracted and absentminded person, so I use computers to help me remember things and take care of mundane tasks. Pretty much exactly the reason I use 1Password. :wink: So when 1Password asks me if I want to update the password, I'm inclined to press "Update" since I want to trust 1Password to do the right thing more than I trust myself.

When we go to test the site the one thing we'll be doing differently is after your step 3. we'll use the Password Generator available in the 1Password mini menu to fill the remaining password fields with a newly generated password. When we do this 1Password creates a Password item with that generated password as a safety net, storing the URL of the page given this happened in a browser.

I might of course just have a very bad memory (I do!), but from my recollection of how this has played out before, I would say that in my experience, no (temporary) password items are created if 1Password has a login item for the website already.

1Password will ask if you want to update and should it find the new password is stored in a Password item for the same site it removes that item, the idea being it has served its purpose. This small change in the steps shouldn't alter how 1Password behaves but it should feel that it flows a little nicer and also won't expand a Login item's password history should you find you have to use trial and error to discover a site's password restrictions (I've suffered this once or twice).

I'll be sure to try this the next time I'm going to change the password of a website. I agree that if it works like you describe, it's a better and simpler process.

The initial test seems to indicate it's working as expected though.

Strange. Might the browser I use affect it in any way? I use Brave.

jxpx777

Generally, the browser shouldn't make a difference for the supported browsers (Chrome, Firefox, Safari, Opera) but Brave has a custom implementation. 1Password accepts connections from Brave but since we do not control the extension in Brave, it's hard to say if something subtle might be going on. It would be interesting to know if this behavior is the same in Chrome. (I say Chrome because its the closest to Brave's implementation as best I understand it.)

asbjornu

I just now changed my password on UserVoice and again, 1Password asked me if I wanted to update the password I already had saved. This time I didn't click "Update", but I'm still dumbfounded on why 1Password asks me to update it in the first place, since the password saved should be identical to the one submitted in the form.

I tried the same thing by @littlebobbytables' suggested procedure in Chrome just now and it worked. It also worked when I did it in Brave, so the problem might be particularly related to the procedure I've been using. The reason I haven't been using the "Password Generator" to generate a new password for an existing Login Item, is because I've experienced the password being "lost in space" that way; i.e. not being created as a Password Item, not being saved on the Login Item and not being copied to the clipboard.

I guess I can rely on that no longer being the case and start trusting that the Password Generator and Update Password dialog in combination does what I need.

All this aside, though: It would be helpful if the act of changing a password for an existing Login Item was something that was a bit more explicit in 1Password's UI, though, so the process was made more intuitive and discoverable. It would also give me more confidence doing it knowing that the way I change my password is 1Password's "official" way to do it.

littlebobbytables

Hello @asbjornu,

Sorry for not replying earlier. I've had a chance to try the steps you normally use and I can replicate your findings. I will write up a bug report as whether we recommend using the Password Generator or not 1Password shouldn't be behaving in an unexpected manner.

I hope my initial question to you didn't come over as confrontational at all, it was merely out of genuine curiosity that I asked about the steps you were choosing to use. You were the first person I've seen say this was how they use 1Password and it does us all good here to learn how our users use 1Password. If there is a "correct" way of using 1Password but users aren't doing so it behoves us to learn why. Is it something is flawed with how we expected 1Password to work, is the interface unclear in some manner and so on. Awareness (on our part) can surely only be a positive thing :smile:

There may have been bugs in the past that I'm not aware of but to the best of my understanding this is how 1Password should and currently works.

Any action that indicates the use of a generated password created by the Password Generator from the 1Password mini menu should automatically create a Password item at that exact moment in time. If the active application is a browser with the 1Password Browser Extension installed and operational the title of the Password item should reflect the site loaded in the active tab and the Password item should also store the URL loaded in the active tab. I am aware we used to have a bug where when people would select the generated password using standard OS X select techniques and then use the OS X clipboard to copy it that a Password item was not created. If memory serves me correctly it was myself that filed that report (based on a user reporting it) and we got it fixed so that it too created a Password item. So no matter if you use the fill button, the copy button or select the text and then use the OS X clipboard it should now create a Password item. After all, a safety net is no use if it isn't always present.

For most users they may not be ever aware that we create these Password items because their lifespan is often quite short. If 1Password correctly recognises that you're on a password change form and offers to update a password it does check for the presence of a Password item with the same new password. If it is present it will be removed once the new password is safely stored inside a Login item. The justification here is the Login item is what the user really wants stored and duplicate/redundant items will only cause confusion long term.

I haven't run into a case any time recently where a generated password was never saved or somehow lost everywhere after updating a Login item but I do understand that if you've felt burnt in the past there may be some reluctance here. I don't know if anything I've written will offer any confidence to give it a try again but what I would say is any bugs reported are taken seriously just as we will take this report seriously too.

The issue has now been reported.

ref: OPM-4383

asbjornu

I've had a chance to try the steps you normally use and I can replicate your findings. I will write up a bug report as whether we recommend using the Password Generator or not 1Password shouldn't be behaving in an unexpected manner.

Excellent!

I hope my initial question to you didn't come over as confrontational at all, it was merely out of genuine curiosity that I asked about the steps you were choosing to use.

Not at all!

You were the first person I've seen say this was how they use 1Password and it does us all good here to learn how our users use 1Password. If there is a "correct" way of using 1Password but users aren't doing so it behoves us to learn why. Is it something is flawed with how we expected 1Password to work, is the interface unclear in some manner and so on.

Yea, as I suggested a "Change password" button on the Login Item would make the "correct" way much more obvious.

The issue has now been reported.

Thanks!

AGAlumB

Likewise, thanks again for bringing this to our attention!

dbates

I use 1Password in this exact same way as the gentleman above, and have the exact same problem. Sadly, the bank website I use makes us change passwords every 30 days. The form has three fields: old password, new password and confirm password. I'm using word generation, but the bank requires at least one number. (Now I'm wondering why I do business with this bank and their ineffective security policies.)

Anyway, I copy the old password into that field, generate a new password from 1Password, modify that password and paste it into the two fields for verification. When 1Password asks me if I want to update and I say yes, it replaces my new password with the old one that I just changed. Obviously, I've stopped doing this workflow because it gives me bad results. I can find my new password in the previously generated passwords area and get it all fixed , but perhaps the point here is that this is unwanted behavior on the part of 1Password.

AGAlumB

@dbates: I agree. It sounds like 1Password is (somewhat understandably) confusing the multiple password fields. Normally I'd say let 1Password fill the new password for you (which helps it know that's the one that needs to be saved)...but of course in your example you can't do that since you need to modify it to comply with the site's password requirements. I wonder if it might be a better option to use character-based passwords (which can be easily generated with numbers, unlike word-based)...but it may be that this poses another issue for you with regard to that particular account. Anyway, we'll see what we can do to make 1Password smarter about these things. Thanks for taking the time to share this example!

littlebobbytables

Hi @dbates,

So just to ensure I'm correctly understanding (the devil is in the details as they say).

1. You edit the actual Login item, generate the new password there and save.
2. Then you go through the process of changing your password on the actual site.
3. 1Password asks if you want to update and when you click Save it overwrites the actual new password with the old one.

I realise you said you were doing the same as the person before but I just to want to make sure we're saying you do precisely the same thing as we have a very wide range of users and sometimes somebody will say they're experiencing the same issue but it isn't. I'm not saying you aren't, I've just learnt it can save a lot of time and confusion if I assume nothing and always try to be very clear about the actions that lead to the bad behaviour.

I have two suggestions that should see better behaviour and mean less fighting with 1Password. This isn't to say there isn't something we still need to address, I wouldn't have written up the report if I didn't believe 1Password needs to do better but there's also helping you in the here and now.

1. If you explicitly saved the new password in the Login item already and know it met all of the site's requirements you could ignore the update login prompt and tell it to go away. Part of what surprised me before was accepting 1Password's offer to update a Login item that the user knows holds the new password but as we discussed earlier in the thread there is clearly work to be done on our side to better communicate and not to mess up.
2. The Password Generator submenu in 1Password mini allows you to edit the generated password before you copy or fill. It's not a perfect answer by any means but instead of saving the new password manually in the Login item before updating on the site you could use the Password Generator on the change password form, edit the generated password so it is a valid password for the site and when you click Fill or Copy this will cause 1Password to save a Password item with that edited password, not the originally generated one. Then, when 1Password asks if you want to update it should update to the new password and remove the now redundant Password item as it's only meant as a safety net. The key bit is the Login item doesn't hold the new password until after the update login prompt has been given the go ahead. This possibility wouldn't be possible if it wasn't for the fact that the generated password can be edited before being used.

My hope is one of those won't seem like a massive shift in how you use 1Password right now but will help by removing the need to extract the last used password and save using it again after 1Password's mistake.

A bank that makes you change your password every 30 days is one of the more forehead banging policies I've seen but to be honest most security policies with financial institutes baffle me. Most UK banks love the idea of asking for individual characters from a password but that just begs the question, how are the securely storing the password that they can verify single characters at random? Best to not question too much lest ye has to make a grab for the heavy duty painkillers.

dbates

Hi @littlebobbytables ,

Thanks for the feedback. Just to be clear, I've already worked around this problem many moons ago. I do exactly what you suggest... I edit the password inside of 1Password, save it, and reject 1Password's request to update.

Once in a while, I will choose the update feature to see if 1Password's behavior has improved. If it hasn't changed, I stick with my old workflow.

All that said, I still believe that this is potentially dangerous behavior, and should be changed. Maybe 1Password could display the password that it's about to update? So there's no confusion? Or, if 1Password is genuinely confused by which password field to update, perhaps it should give you the choice? As in, here's what I think is the new password, am I correct?

All this is assuming that the logic inside of 1Password can't be changed to correctly parse the password fields that the website is showing.

AGAlumB

Unfortunately there is no clearly reliable way to have 1Password differentiate between multiple password fields on the same page. The way they are identified will vary from site to site, and these types of logins are a bit obscure to begin with. Having the user confirm it though is an interesting idea. On its face, it seems rather burdensome and annoying, but if we can find a way to have 1Password prompt only when there are duplicate fields that may be a good option. Thanks for the suggestion! :)