Login suddenly fills incorrect fields, creation of new manual login doesn't fix problem

mblatchford

I have a longstanding login on my banking website. A few days ago I noticed the cmd-/ shortcut no longer filled in the username/password fields correctly. The login information has not changed and the banking site hasn't had any aesthetic changes but I think something happened behind the scenes. My username now populates in a search box expecting a zip-code while the actual username and password fields stay blank.

I went ahead and moved the login to the trash, manually added my username and password to the appropriate web fields and then with the extension selected "save new login". I refreshed the page and attempted to use the cmd-/ shortcut and while it appears to fill in the fields correctly (dots in place of password characters), never actually saved the password. The extension shows only the username had saved. Clicking on the edit button, adding the password, saving it and trying again with the shortcut reverts back to the username filling out in the wrong field entirely and no password filling in.

While this is mainly occurring in Safari 11.0.3 I did test it with current versions of Firefox and Chrome to the same effect, hence believing the website itself changed something under the hood. Strangely enough, there is a possible 1Password bug - when the manual login fails to save the password and I go into the extension and edit the login pasting in the correct password, the correct password is saved and can be copied however the password strength "meter" doesn't update to reflect what I've added staying at the extreme minimum red bar when I know it's a solid randomly generated password 20characters long.

I can redact and post the webform fields 1Passwords sees or post a link to a screencast of the login behavior etc if that would be helpful.

Thanks!

---

1Password Version: 6.8.6
Extension Version: 4.6.12
OS Version: 10.13.3
Sync Type: Dropbox

AGAlumB

@mblatchford: Unfortunately it's impossible for us to test this without the URL. Can you share that here, or would you prefer email? However,

the password strength "meter" doesn't update to reflect what I've added staying at the extreme minimum red bar when I know it's a solid randomly generated password 20characters long

If you've manually edited the password, 1Password isn't going to treat it as "random", as it did not generate it itself. That's expected.

ref: OPM-5256

mblatchford

I'm not concerned with giving out that info I use 1Password :) The page in question is schoolsfirstfcu.org. Not sure I tracked with the meter explanation. If I create a login and a password the meter gauges the strength of what I come up with just as it does if I used the built in password generator. In this scenario, I copy/pasted the password I had been using for this login (which incidentally 1Password had originally generated itself), into the new manual login and the password meter did not change. Am I to understand something in the act of pasting a password vs typing it out changes the meter behavior?

AGAlumB

I'm not concerned with giving out that info I use 1Password :) The page in question is schoolsfirstfcu.org.

@mblatchford: Thanks! I was able to save and fill a login there using 1Password. In many cases manually saving a new login for the site will allow 1Password to save additional information from the form to fill better. Just try these steps to save the login manually:

1. Navigate to the website
2. Enter your login credentials
3. Click the 'keyhole' icon to bring up the extension
4. Click the 'gear' icon for Settings
5. Click Save New Login
6. Give it a name and Save
7. Close the webpage and select your new login from the extension to have 1Password Go & Fill
8. Submit the form manually if you have autosubmit disabled

Let me know if that helps. :)

Not sure I tracked with the meter explanation. If I create a login and a password the meter gauges the strength of what I come up with just as it does if I used the built in password generator. In this scenario, I copy/pasted the password I had been using for this login (which incidentally 1Password had originally generated itself), into the new manual login and the password meter did not change. Am I to understand something in the act of pasting a password vs typing it out changes the meter behavior?

Correct. When you paste or otherwise manually enter a password, for all 1Password knows, you've made up the password yourself (which is going to be decidedly un-random), so it will treat it skeptically and display it as significantly weaker than if you'd generate a password using 1Password itself. If you use the strong password generator to save a random password using 1Password, without human interference, it knows exactly how much entropy it has, so that is reflected in the strength meter.

I hope this helps. Be sure to let me know if you have any other questions! :)

mblatchford

I appreciate the help, unfortunately I'm not seeing any difference in the steps than what I've done previously. Here is a screen cast of the issue. https://www.dropbox.com/s/rtmak8gbubz4vsx/1password.mp4?dl=0 You can see I input a username and password and save a new login. When I use the go and fill it fills the appropriate form boxes but there isn't an actual password being saved to the login. Then when I do paste in and save the password, go and fill reverts to filling out the zip code box and not the correct web form.

fahrennheit451

I'm experiencing the same thing on Safari 11.0.3 on macOS 10.13.3.

littlebobbytables

Hi @fahrennheit451,

If you are referring to the exact same site then the follow will apply to you as well. If it's a different site this may not explain what you're seeing because every site can be very different.

Hi @mblatchford,

The recording helped identify the issue straight away. You notice how in the password field you can see the last character whilst the rest are obscured? This is the site trying to mimic an iOS feature aimed at spotting typos as you mash the virtual keyboard as best you can. They're using a text field and JavaScript to make it look like a password field and this isn't something 1Password can easily detect or correct. I believe the following should work though so I will be interested in learning what you observe after completing the steps.

1. Manually save a new Login item using the steps detailed on our page How to save a Login manually in your browser.
2. Switch to 1Password, select the new Login item and enter edit mode.
3. Do not enter a password into the password field. Instead click the button titled show web form details.
4. You will see a number of fields listed. One will contain your username and has the silhouette of a person to the side of it. The field under it will have a series of dots and a single visible character. This is the field we're interested in.
5. Replace the ••••••• with your real password.
6. Click directly below the silhouette of the person and in the little menu that appears for the password field select the icon that is the silhouette of a key.
7. Save.

You should find that your password appears at the top and displays your real password. What we've done here is correct 1Password's understanding of the page and told it which field represents your password on the page it saved as well as ensuring 1Password has your real password saved and not a series of dots. Does this modified Login item work better, correctly filling and allowing you to log in?

fahrennheit451

I am indeed talking about the same site, and after following the steps above, I'm still experiencing the same issue as in the screen cast, where the username gets populated in the zip code field at the top, and the user name and password form elements on the page remain empty.

littlebobbytables

Hello @fahrennheit451,

Can you help me out please with the following request.

1. Follow the steps I detailed in my previous post but this time use completely fabricated details e.g. username & peekaboo.
2. Confirm the filling issue using this fake item.
3. Enter edit mode once more and click on the show web form details button.
4. Create a screenshot of the item details pane. The site How to take a screenshot can help with this if you're unsure.
5. Check the screenshot contains nothing sensitive and add the screenshot to your reply.

I'm trying to figure out why those steps work for me but don't for you so I'm hoping I notice some difference that might explain the contrasting results. Obviously we cannot do this where the screenshot captures any real details hence the dummy Login item with the fake credentials.

fahrennheit451

Ok. So, some strange behavior. If I enter username and peekaboo, Save new login, and don't edit anything, the form filling seems to work. But once I've edited the field and marked it as a password, the previous behavior of not filling the form and putting the username in the zip code field occurs.

Attached are the unedited login, and the edited login, for your perusal.

Unedited

Edited

littlebobbytables

Hello @fahrennheit451,

Thank you for those images, they were most informative. I see you flagged the field correctly (silhouette of the key) but you seem to have changed the field type from text to password. Even though it is the password field the site uses a text field so it needs to remain as the text type for it to work. Do you find reverting it to the text type has 1Password fill?

fahrennheit451

Yes! My mistake. Once I changed it back to text, it submits AND allows for login (no incorrect password warning). One thing that doesn't work is auto-submit, and I've tried that with the regular fill and submit key command, and tried the setting for Always submit. But it's working much better than before. Any thoughts on that last bit?

mblatchford

@littlebobbytables I can confirm along with @fahrennheit451 that the solution ultimately worked for me as well. It's still not auto-submitting as @fahrennheit451 mentioned, but at least I can use the keyboard shortcut and an additional "enter" keypress and I'm in. Not totally ideal, but workable.

littlebobbytables

Hi @fahrennheit451 & @mblatchford,

I was about to say I'll have to investigate but after a moment I realised what was happening. We have a security measure in place where we only submit after filling if:

1. It is enabled either for the item or globally.
2. We fill a password field on the page.

Why 2? It's a precaution against accidental filling and it gives the user a chance to not proceed if needed. If we fill an actual password field though we're usually pretty confident and can go ahead. Now the 1Password application understands its filling your password but we don't tell the extension this, merely interact with this field and set it to xxxxx. So the extension can only go on if it's a real password field or not which this page doesn't use. There isn't a way to force submit after filling in this scenario I'm afraid so I hope the manual submit using the enter key isn't too annoying.

fahrennheit451

Sounds good to me and the explanation makes sense. Thanks for the help!

mblatchford

@littlebobbytables could the extension be updated to allow for auto submission if the field has been given password status manually? As I understand it the website isn't set up with a proper password field anymore. Our manual creation of a login keeps the password field saved as a text field till we changed it. We had to go in and switch the text field to the password icon so could the extension compromise rule 2 that if the field is overridden to be a password field it will then allow the auto submit? Or is there still a flaw in the logic somewhere?

littlebobbytables

@mblatchford,

What those steps did was to ensure 1Password displayed your password for this site by properly flagging the right field as containing your password. The field on the page though is a text field and the site uses JavaScript to make it look like a password field by replacing the characters with the dots. None of that information though gets passed to the extension, we simply say fill this field with this value as the extension doesn't need to know if the field represents your username, password or even something else. As this knowledge is never passed the extension cannot be readily tweaked to use it. The downside are pages like this that decide to use something other than a traditional password field which is of course ideal for passwords.

While I won't say we'll never consider it, it's an edge case and a lot of tasks will take precedence. I just don't want to build up false hope and have you believe it will be thrust to the top of the queue. Don't get me wrong, I do understand it takes away from part of the automation that we've all become accustomed to but we are also painfully aware of sites where we struggle to fill at all and need to attend to these as well as ensure the extension continues to work properly as browsers change. I hope that isn't too disappointing and that you still find value in 1Password based on its overall effectiveness.

mblatchford

Oh I get it. I was mostly curious if it were technically feasible. I got 90% functionality back, I'm happy. Thanks for the assist.

littlebobbytables

It would be nice if we could easily do better here, the tricky part is finding a way based on the current implementation that also ensures we don't accidentally submit where we shouldn't. Sometimes we have to air on the side of caution. If you come across any other odd sites please let us know.