Autofill has serious security issues

ilolita

When a user visits a webpage that has been tampered with, for example, a transparent fill-in box with a size of ten pixels is displayed on the page, and it is hidden in a very hidden corner.

At this time, when the user uses the padding, it will also fill in the username and password hidden in the corner.

I think this is a very serious problem, and you should solve this problem as soon as possible.

I hope to only fill in the user name and password in the input box that has been clicked by the mouse, instead of filling in all the forms on all pages that require the user name and password. This is wrong.

ag_yaron

Hey @ilolita ,

1Password uses a combination of field focus, the original details of the fields themselves when the login was originally created and the internal "brain" of 1Password that reads the page and makes educated decisions on where it should and shouldn't autofill to make sure we fill in the correct fields and not in any other fields

Did you personally encounter a website where 1Password autofilled wrong/malicious fields? Was the login item recorded directly from the page or was it created manually through the 1Password app? Are you able to share a link to such a website so we can test and investigate the issue?

ilolita

Hey @ag_yaron ,

This is an error page effect generated after the user script is modified, but this can already prove that the automatic filling of 1password is defective, and it will mistakenly believe that other login boxes also need to be filled automatically.

There is also a security report for this content, which makes me very worried. I want to know when you will be able to solve this autofill security issue.

Attach a link to the original text, it is a pdf file.

Please read section 6-2 for details, thank you.

https://www.usenix.org/conference/usenixsecurity20/presentation/oesch
https://www.usenix.org/system/files/sec20summer_oesch_prepub.pdf

jpgoldberg

Hello @ilolita,

That is a really fine paper, and the authors shared prepublication drafts of the paper with us. Research like this is extremely valuable to us, and it is also why someone from 1Password has attended Usenix Security most years over the past six or seven years. (Of course Usenix Security this past year was held entirely on line.)

In the loop

One thing that you will note is that 1Password always requires some user action (even if it is just ⌘-\ or Ctrl-\ ) before filling and we always have.

This is because from the outset, we have been aware of these kinds of threats. This is acknowledged in Sean and Scott's paper, for example with

KeePassXC, 1Password X, Dashlane, and LastPass autofill within same-origin iframes, leaving them vulnerable to clickjacking attacks. Bitwarden and RoboForm also autofill within same-origin iframes, though if user interaction is required they are largely immune [emphasis added] to clickjacking as this interaction happens outside of the website inside the extension drop-down.

With 1Password user interaction is required for filling. Always has been, always will be. We also do not allow cross-origin iframe filling. This means that when the tells 1Password to fill a page, the user knows what page really is being filled.

A few years ago, attacks like that hit the news, and I we up a bit about it in 1Password keeps you safe by keeping you in the loop. That is what addresses your primary concern, and is reflected in the "Interactions" column in their table 7.

Other points

Some of the other things that are mentioned in table 7 are the result of design choices and interactions. You will note that no password manager respects autocomplete=off (as banks tend to use that setting to actually discourage use of password managers). And others involve trade-offs and interactions, as when 1Password X performs the filling depends on what sorts of checks it can perform. In fact, 1Password analyzes the page twice. Once when identifying which logins it knows about that match the page and again later, closer to form submission time, to make sure that the page hasn't changed in the meantime. So there are a lot of fairly complicated interactions among these.

There is a division of labor between the browser and 1Password X for a few things. For example, the 1Password browser extension doesn't know whether there is a bad certificate for a site, but the browser does. So we have to ask the user to pay attention to browser warnings and not fill into sites that the browser tells you may be inauthentic. This, by the way, is another place our insistences on user interaction plays you: 1Password will never give up any of your secrets simply by you visiting a site.

I hope that this helps. And we will continue to work with the academic research community on the security of 1Password. And I really hope that I will be able to physically attend Usenix Security (and SOUPS) this year.