1P browser extensions will fill every text field, even when others match (WordPress incompatibility)

Per this tweet, it seems that 1Password is designed to obey the web form fields if they are present on the page. If not, 1Password reasonably will try to find appropriate fields (registration versus login forms are different; it makes sense to be as compatible as possible). However, even when all fields are properly present on the page, 1Password will additionally attempt to fill in every text field anyway.

This poses a major problem in WordPress, which pops up a login in an iframe when your cookies expire. Once the iframe closes on auto-submit, all text fields will suddenly be filled with your username. This would affect editing a post, editing settings, etc. Very messy. I would expect this would affect any site with a pop-up login that doesn't require a full-page refresh, and in general any site implementing things without full page refreshes.

There are many possible fixes here. Probably the most limited fix (one with the least chance of breaking things for other users) is, if all web form fields match within the iframe, only touch other fields that are within the iframe. Obviously, this is limited and won't fix other side effects. It will, however, solve most difficulties I've seen reported with WordPress. (There are other issues, of course. If a login field has an additional two-factor authentication text input, 1Password will fill it, even though it wasn't configured to do so.)

I'm a WordPress lead developer; here's the ticket we are using to track this issue. There are steps to reproduce there that are specific to WordPress.

Tested with 1Password for Mac 4.1.2 (on Mavericks), Chrome extension 4.0.1.99, Firefox extension 4.0.1.

The tweet I linked to above was in reply to a request for some technical details on how exactly 1Password determines which form fields to fill. We may need to make separate adjustments for saving the right credentials on user creation and site installation (it grabs the email instead of the login). These kinds of details are very important to web application developers.

Here's a simple HTML form example. Note the other input fields aren't even inside a form tag. 1Password doesn't care, even if the web form details are properly configured for "log" and "pwd". They can be in the same form, or in a separate form, or in another frame, it doesn't matter, 1Password will fill them. That includes filling over other data that is already present, which can potentially be destructive. :-(

Comments

  • There are a couple of specific cases where the 1Password extension (doesn't matter what browser, Chrome, Safari, Firefox) gets carried away when filling in forms, and starts stuffing the saved login in name in any extra fields.

    There are a couple of primary places this tends to crop up.

    The first is bank web sites, where commercial accounts often have two usernames -- one for the organization and one for the user within the organization (and many of which want the two usernames on one page and the password on the next one often with some joke pseudo-security in between). This is the two-username case.

    The second is websites that use two-factor authentication. This is the two-password case, although the 2fa code often isn't in password field since the person needs to be able to make sure they're entering it properly from the device or other source.

    It seems like for these types of web sites, only one username is supported and 1Password stuffs that one username in any field it doesn't recognize.

    There actually is a third type, a software package we use with a web interface that has a login, password, and then a couple of additional fields for authentication realm and language settings which are, regrettably, implemented as text entry with long descriptions. 1Password stomps these fields with the username as well. Even worse, changing the language settings reloads the page, so it's impossible to log in to this web UI with 1Password.

    This behavior actually started several versions ago, sometimes around the 2.x to 3.x timeframe. Before that, it used to work as expected. Since then, I've just been living with it. Auto-submit has to be turned off, obviously, but from there it's just a matter of typing over the wrong entries and avoiding it where it doesn't work at all.

    But more and more sites are making use of 2-factor authentication, so it would be really great if this behavior could be adjusted a little bit. Seems like that would be two things:

    • Support for logins that require multiple usernames.
    • Leave unrecognized fields alone rather than populating them with the username.

    Is that functionality that we're ever likely to see?

    Thanks!

  • Hi @jdwx,

    I'm sorry to hear that you're having trouble with filling here! We are always looking for ways to improve 1Password's form filling abilities, but we do depend on sites being labelled in a standard way. If a site using unconventional methods in the naming of form fields, it can be difficult for 1Password to fill correctly. You can help 1Password behave better on many of these tricky sites by manually saving a new Login. Let's try this:

    • Edit the login that you currently have for this website by appending an "Old" to the title - just so you can tell them apart.
    • Visit the site and fill in the fields you want filled. Do NOT click the login button.
    • Click the 1Password extension, and unlock it if necessary
    • Click the gear icon (or vault icon if multiple vaults are enabled) in the upper right corner.
    • Select Save new login.
    • Give the entry a unique and identifiable title.
    • Click Save.
    • Revisit the site and see if 1Password fills in the site correctly.

    If that doesn't work, could you let us know addresses of some of these problem sites so we can do some testing here?

  • Let's not blame the sites here. They are not "nonstandard" or "unconventional." In fact, the banks involved are particularly quick to point out that they are adhering to industry standards for online security; they are required by regulations not to use just username and password for logging in. Two-factor authentication for other sites is also getting much more popular very quickly.

    I have been working on this for several days trying to understand the new and different behavior of 1Password 4. Here is what I have found:

    The "save a new login" approach sort of works for one of the bank sites as long as you are willing to have and maintain two different "logins" for the site, one containing the two login names name. That's problematic since these are the same sorts of sites that force constant changes and also randomly throw up "security questions" that have to be tracked (since companies don't have favorite sports teams or first pets).

    The "save a new login" approach made no change for the internal web UI. Even with all fields filled exactly correctly, it still robo-fills all the fields with the login name. Upon inspection, it looks like it doesn't even save anything related to the form values other than username and password. Old versions saved every field and allowed the user to select which was the username and which was the password. Is that functionality really gone?

    The "save a new login" approach doesn't work at all for sites that use two-factor authentication. Simply nothing happens when "Save new login" is clicked unless every field is filled in.

    As you can imagine, I am not particularly enthused about posting a list of my employer's banking and credit card processing web sites on a public forum. And posting the internal address of the web UI wouldn't do any good. Here's one you can test though:, my web host's login page: https://members.nearlyfreespeech.net/

    That one is of the "uses 2-factor, doesn't work at all with 'Save new login'" variety. There's nothing 'non-standard' about it. If you view source, it's half a page long, no frames, no javascript, just three form fields, appropriately named, for login, password, and OATH code.

    Thanks!

  • I did find the "Show web form details" button finally, so at least the needed info is still there. (Whew!) It's just being ignored.

    If I fill the web host site login page in completely, including the temporary code, it will save. Then if I try to use that to log in, it fills the temporary code. Which is the opposite behavior of the web UI.

    If I edit the 1Password entry, it shows it thinks the temporary code is the login. If I change the login to the correct field and change the value of the temporary code field to be blank, it appears to work as expected, some of the time.

    After more trial and error, I was able to figure out what was causing it to overfill sometimes but not others. If the URL is an exact match, it seems like it generally will not overfill. If it is not an exact match, it will. There may be other triggers as well, as I have observed wildly inconsistent behavior on this over the last week.

    Thanks!

  • khadkhad Social Choreographer

    Team Member

    Hi @nacin,

    Thanks for taking the time to contact us (and with such a detailed report)! Sincere apologies for the trouble.

    The "promiscuous filling" is slated for removal in an update to the extension(s). The fix won't be in the next extension update (4.1), and I can't promise a specific release. But it is definitely on our radar for resolution very soon.

    Again, it is not available yet, but if you are interested in trying the fix as soon as possible, you may want to switch to the beta channel for the 1Password extension in at least one of your browsers. (The beta channel is separate for each browser extension.)

    I'm sorry I don't have a more immediate solution, but I hope it helps a bit to know that this is something we are actively working to improve.

    We may need to make separate adjustments for saving the right credentials on user creation and site installation (it grabs the email instead of the login).

    It sounds like you are describing the issue in this other thread. If so, could you follow up there? If not, please let me know some more details as it seems I have misunderstood.

    Cheers!

  • PhilippeAGPhilippeAG 1Password Alumni
    edited February 2014

    Hello @nacin, I'm working on the extension.

    I agree, the current version is way too aggressive when it tries to fill, we tweaked the aggressiveness factor (just try a login on united.com - it's so much fun). The next version should now behave better in these cases. With the increasing number of Webapps (like iCloud.com) and sites that don't reload the page when an action is submitted, we need to rethink our approach, be more stateless when you click the fill button and not overwrite data.

    The next version (it's not even in beta) of the 1Password Extension for Chrome/Firefox/Safari will (almost) ignore HTML forms when filling; this is because sites like united.com (one form for the whole page) and https://www.adobe.com/account/sign-in.adobedotcom.html (no forms at all) have creative use of forms and their elements. There's a lot of them out there, it's impressive. We can't just work with "well-coded" sites, we have to do our best effort to fill the right stuff every time on every site.

    We also made sure the extension will give up filling before overwriting too much data now; we won't blindly put the user name in every text field and the password in every password field when you try to fill a login.

    As for the small form you posted, it would indeed trigger the "FILL ALL THE FIELDS" algorithm; the names aren't recognized, there is no labels, no id and the form has no action.

  • Hi @khad, thanks for the comment. Unfortunately me installing the beta version won't solve the problem, as I'm not really interested in solving this for myself. As I'm actually aware of the bug, I can work around it.

    Rather, I'm interested in the probably the tens of thousands users of 1Password who also use WordPress regularly, and for whom this bug will catch them unsuspectingly. The list of 1P + WP users includes a majority of the members of the WordPress core team and what's probably a sizable minority of employees of Agile Bits.

    These users will accidentally update the title of their site from "Agile Blog" to "khad", or worse. They may blame it on 1Password, or they may blame it on WordPress. Or they may not notice it happened right away and have no idea how it happened, or they'll think their site is hacked. No matter how you slice it, it's a terrible experience for the user.

    If I were classifying priorities, I'd say this is a pretty nasty bug with pretty terrible side effects. But if it's not a priority, that's fine — I'm not necessarily looking for a fix. I imagine WordPress will be able to move faster here by offering a fix in our next major version, due in April. What would be best is if I can receive a detailed technical explanation of how 1Password's filling actually works. Then we can smartly work to circumvent the "promiscuous filling" for all WordPress + 1Password users.

    Could I also suggest that the 1Password Twitter account not tell people 1Password doesn't do something it does?

  • nacinnacin
    edited February 2014

    Hi @Philippe-AG, thanks for the reply!

    WordPress strives to work on pretty much every setup and around every bug out there. I totally understand the need to bend over backwards to make things work everywhere. Making things "just work" for users is rewarding but also a huge challenge.

    The example I posted was, of course, an extremely reduced version. I reduced it until I could no longer reproduce the issue, which is to say, I could always reproduce the issue. I had that page configured specifically for the "log" and "pwd" fields. I'm not entirely sure why, if it's configured and all fields match, it would additionally try to fill other fields, but I'm sure you have seen something funny in the wild. (Is "the names aren't recognized" an internal whitelist issue? I'm referring specifically to problems when these fields are are already saved under "web form details".)

    The WordPress login form uses a form (with a name, id, and action), labels around and "for" inputs; and even when configured specifically for the proper fields, other fields outside of the iframe pop-up still get filled.

    The changes you have made seem very promising. Is there anything I can do to help test what you have for the new version on WordPress? Whether that's receiving a binary to test or providing a test script. If your next version works, then depending on its tentative timetable it'd take some of the pressure off for us to come up with a workaround for the meantime.

  • khadkhad Social Choreographer

    Team Member
    edited February 2014

    Thanks for following up, @nacin.

    Could I also suggest that the 1Password Twitter account not tell people 1Password doesn't do something it does?

    I'm not sure what is incorrect about that Twitter post. It is not the complete story. I suspect that is why @1Password directed you to follow up here so we could explain the situation in more detail as I and @Philippe-AG have been doing. But there is nothing incorrect in it.

    It looks as though perhaps you posted while @Philippe-AG was replying. I hope you didn't miss his post. He is the one working on the extension and would be able to better assist you with the specific technical details.

    It also sounds like perhaps I wasn't clear about how much of a priority this is for us. We don't normally discuss future plans as many factors affect their inclusion and release dates (as I'm sure is the case for WordPress as well). However, resolving this is absolutely a priority. Version 4.1 of the extension is already in beta, and I wouldn't be surprised to see this issue resolved in 4.2. But again, I cannot promise anything specific.

    I'm interested in the probably the tens of thousands users of 1Password who also use WordPress regularly, and for whom this bug will catch them unsuspectingly.

    We're working as quickly as possible to resolve this, but it is a pretty substantial change. We want to be sure it is thoroughly tested before being rolled out in silent extension updates for all 1Password users.

    If we can be of further assistance, please let us know. We are always here to help!

    EDIT: Looks like it happened to me too. I was posting while you were replying to Philippe. :)

  • Hey @khad — "If the fields saved in a Login item don’t match the ones on the page I try to fill what I can" is indeed not the complete story. The problem is that even if fields saved in a Login item do match the ones on the page, 1Password does still try to fill in what it can anyway. Not trying to make a big deal about it.

    I'm not looking for promises — it just helps to know if whatever you are currently testing in alpha does appear to fix the incompatibility with WordPress, as this becomes something we no longer need to worry about, as the fix will eventually come to users. But if the ongoing adjustments don't yet help with the issue, we may be able to make adjustments on our own in the meantime.

    Thanks for the help, both of you!

    P.S. We're open source and community-built, so our tentative 2014 schedule is, for better or worse, already laid out. :-)

  • PhilippeAGPhilippeAG 1Password Alumni
    edited February 2014

    (Is "the names aren't recognized" an internal whitelist issue? I'm referring specifically to problems when these fields are are already saved under "web form details".)

    Yes, it's worse case. The web form details don't match and we need to figure out where to put stuff.

    The WordPress login form uses a form (with a name, id, and action), labels around and "for" inputs; and even when configured specifically for the proper fields, other fields outside of the iframe pop-up still get filled.

    But probably the field names don't match the saved web form details in 1P; we're back to guessing. We're a bit strict in matching; the form method, action and name should, ideally, match the saved details. This is because some sites like to change field ID, Name every time

    The changes you have made seem very promising. Is there anything I can do to help test what you have for the new version on WordPress? Whether that's receiving a binary to test or providing a test script. If your next version works, then depending on its tentative timetable it'd take some of the pressure off for us to come up with a workaround for the meantime.

    Not right now, I broke Firefox and Safari so bad... I'll need super glue before starting to test in the "wild"! It also so full of debug that it's very slow. We hope to have it in beta sometime soon... as soon as our automated tests passes.

  • PhilippeAGPhilippeAG 1Password Alumni

    Hi @jdwx,

    I think you're experiencing the same issues as @nacin. This has been toned down for the new version of the extension and hopefully we should be able to support "bank" style logins soon.

    As for 2FA, I'd personally like it but it's not very hight priority. We should leave the token field alone with the next version however (and not auto submit).

  • nacinnacin
    edited February 2014

    Here are the two forms:

    Nothing changes and the field names match what's in 1Password.

    In separate tests (with nothing for that site in 1Password), I logged in and saved credentials using both forms. I then exported the entries and compared the resulting JSON. Inside secureContents, the values of the keys htmlName, fields (the entire array of objects), htmlMethod, htmlAction, htmlID are all identical. It doesn't stop 1Password from filling in fields outside the iframe or any other extraneous text fields I selectively add.

  • PhilippeAGPhilippeAG 1Password Alumni

    Hi @nacin,

    It's a bit hard for me since I only run the development version by now, but I know what is happening. I'll try to reproduce it with the new version and tell you about it.

  • jdwxjdwx
    edited February 2014

    @Philippe-AG

    "But probably the field names don't match the saved web form details in 1P; we're back to guessing. "

    It should be made clear that this is not an accurate problem description. It is sufficient for the saved URL to be in any way different from the current URL, even if it's for the the same site. The form field names can be identical and it will still shift into "fill everything" mode.

    E.g. if the saved URL is:

    http://example.com/login

    Then any of these will cause manic filling syndrome:

    http://example.com/
    http://example.com/login/
    http://example.com/login/extra_path_info
    http://example.com/login?
    http://example.com/login?fwd=next_page

    Even if all the fields (indeed, all of the page content) are the same.

    "As for 2FA, I'd personally like it but it's not very hight priority."

    You're not being asked to support it. (Although integrated OATH support in 1Password would be very cool.) You're being asked to stop burning people who use it. (Which, happily, it sounds like you're working to do.) Those are people who care about security, which are disproportionately likely to be users of tools like 1Password. Dismissing it as "non-standard" and "unconventional" (as @Megan did) is not an appropriate response in today's security climate. Demand for 2FA is through the roof this year, probably driven by stories that hit the press about prominent Twitter name theft and domain hijacking in the past couple of weeks.

    @nacin

    "These users will accidentally update the title of their site from "Agile Blog" to "khad", or worse."

    Yup, now that you mention it, I had a WordPress blog entry mysteriously change the post title to my 1Password-saved username a couple of weeks ago. Mystery solved!

    Thanks!

  • Also, I guess I should ask the material question: with the understanding that you can't commit to a specific release time, can you give an impression about whether we can look for the improvements you're working on in more of a 4.2 timeframe or a 5.0 timeframe?

    Thanks!

  • khadkhad Social Choreographer

    Team Member

    From my post above:

    "We don't normally discuss future plans as many factors affect their inclusion and release dates (as I'm sure is the case for WordPress as well). However, resolving this is absolutely a priority. Version 4.1 of the extension is already in beta, and I wouldn't be surprised to see this issue resolved in 4.2. But again, I cannot promise anything specific."

  • PhilippeAGPhilippeAG 1Password Alumni

    Hi @nacin,

    Just tested with the new version and it does behave the same way (trying to fill every frame), but I'm not giving up. We just need to get a beta out ASAP. I've completely removed the "FILL-ALL-THE-FIELDS" algorithm.

  • MrCMrC Community Moderator

    I've completely removed the "FILL-ALL-THE-FIELDS" algorithm.

    Hallelujah!

  • khadkhad Social Choreographer

    Team Member

    Hallelujah!

    Said in my best politician voice: "Thank you for letting us know you are excited to see this upcoming change." :)

  • PhilippeAGPhilippeAG 1Password Alumni

    So Beta 4.2 is out with much needed changes if any of you want to take it for a spin. You can download it from https://agilebits.com/browsers/index.html just make sure you click the "Feeling adventurous? Enable betas" link.

  • nacinnacin
    edited February 2014

    Hi Philippe, thanks for the amazing turnaround! Sorry for the delay, I've been traveling and also didn't have email notifications enabled.

    I've tested 4.2.0.2 Beta in Chrome and it works as expected! However, I can't get it to auto-submit on any site (I have it configured for both the extension and the individual login). Is this just is a debugging flag for the beta, or something different? I tried uninstalling and re-installing.

    I am going to point some WordPress contributors at the beta and will collect their feedback.

    Separately: Is it OK if I report a bug with the downloads page here? Clicking "Enable betas" changes the URL to "?beta=true" and adds the bug to the "Install" button, but it doesn't toggle the "Enable betas" text. Clicking the text again (to try again to enable it) shifts it to "Disable betas" and disables it. Then clicking "Disable betas" enables it again, and so on.

  • PhilippeAGPhilippeAG 1Password Alumni

    Hi @nacin

    I've tested 4.2.0.2 Beta in Chrome and it works as expected! However, I can't get it to auto-submit on any site (I have it configured for both the extension and the individual login). Is this just is a debugging flag for the beta, or something different? I tried uninstalling and re-installing.

    I'm glad the new beta works better! As for the auto-submit, we noticed we broke it and will be fixed in a later beta.

    Separately: Is it OK if I report a bug with the downloads page here? Clicking "Enable betas" changes the URL to "?beta=true" and adds the bug to the "Install" button, but it doesn't toggle the "Enable betas" text. Clicking the text again (to try again to enable it) shifts it to "Disable betas" and disables it. Then clicking "Disable betas" enables it again, and so on.

    I'll go and bug the web devs for you :)

    Phil

This discussion has been closed.