"Researchers expose vulnerabilities of password managers"; what about 1Password?

@XIII - thanks for asking. Research, like the sort reported, is extremely useful in helping us and the whole information security community improve our systems and products. And so it has, particularly when the authors of this study contacted us in the course of their research in 2017. But academic research of this nature can be misread by the public. The versions of 1Password that were examined in that study were from June and July 2017, as you can see in the paper's Table 1 on page 6 (1Password for Windows 6.6.439, released 2017-06-19, and 1Password for Android 6.5.3, released 2017-07-05).

As is the convention for such research, the researchers talked to us before making their findings public and gave us the opportunity to fix things that needed to be fixed. The research, and publication of it now, does have real value both to developers password managers and for future examination of password managers, but given its historical nature, it is not a very useful guide to the general public in assessing the current state of password manager security.

Regarding the lack of enforced limitations you mentioned on Master Password entries in 1Password apps, we intentionally chose well before this research not to limit such attempts because it's much more likely a user might lock themselves (even temporarily) out of their data by failed Master Password attempts through the app interface than it is that an attacker would try to use the app interface to attempt a brute-force attack on a user's Master Password. Any competent attacker who gains remote or physical access to a device to such a degree that they can launch an application and make or automate guesses through the UI could even more easily extract the user's encrypted 1Password data file, transfer it to disk and then run much more-efficient (and therefore faster) GPU-enhanced cracking tools on it at their leisure, without fear of detection.

But it is through work like the authors' that password managers are better secured today than they were three years ago. If you click through to the paper itself (released only recently on March 4, 2020), you may note when you read it that the authors do mention some of their discussions with us from when they were conducting the research. Here's a link to the paper itself.

We look forward to them or others re-examining the current versions of 1Password with respect to the kinds of vulnerabilities that they discussed -- and of course, like always, we're happy to answer questions.

On behalf of Lars you're very welcome. :)

Ben

Hi @bdgalloway,

You asked for more detail on these issues

• URL mismatches
• HTTP(S) auto-fill
• Ignoring sub-domains

For all of these, it is important to understand how 1Password helps keep you safe from phishing. So let's give a simple phishing example. Suppose you have a login in 1Password saved for https://www.paypal.com/ with a username and password. Now suppose you can some email that appears to be from PayPal, telling you that you need to sign in to do something. That email might contain a like to https://www.pavpal.com/. The site, with the "v" where there should be a "y" is carefully crafted to look like the genuine PayPal service. But the www.pavpal.com domain is controlled by thieves. They want you to enter your genuine PayPal username and password into their malicious site.

1Password will not fill in a passed saved for paypal.com into pavpal.com. Even if you don't see the difference between the "y" and the "v", 1Password does. So when you ask 1Password to fill that page, it won't be offering up your password that is saved for your PayPal account. The phishing site needs to trick both you and 1Password to get 1Password for fill that in for you.¹

So broadly speaking, 1Password has saved the URL for the page, and when seeing what to offer to auto-fill, it checks if the URL "matches" the page it might fill in. The only relevant parts of the URL used for matching are the "scheme", and the "host".² The scheme is the "http" or "https" part. The host is the "www.paypal.com" part.

Don't fill HTTPS credentials into HTTP

Until relatively recently, it was common for sites to have both an http and an https version. So for example, you might up for some service as https://www.foo.example and have the username and password in 1Password for it that way, while you might end up logging into http://www.foo.example. Note that the latter is HTTP, and so its identity and communication are not protected by TLS.

Question: Should 1Password offer to fill in what you have saved for https://www.foo.example into http://www.foo.example?

The fact of the matter is that our answer changed over time. Ten years ago, the answer was "yes". Four years ago the answer was "maybe". Today the answer is "no." The change isn't because our view on the security issues has changed. What has changed is that as the world has been moving toward https everywhere, we don't cause as much problems for our users by saying "no". Ten years ago, there would just be far far to many services that where offering the same things over both HTTP and HTTPS that we simply couldn't have said "no" without causing a great deal of grief.

When our answer was "maybe" it was that we were making the transition from "yes" to "no". 1Password on the desktop said "no" because it could pop up a warning and help people go to the HTTPS site. But we rolled this out more slowly on mobile. I haven't dug through the precise history to see the state of all of the clients back in the summer of 2017, but as reported in the research paper, 1Password for Android was saying "yes".

Some of these sorts of tough decisions (though it is an easy decision today) reflect some of the complexities of these decisions. We could make the "no" much less problematic for people on the desktop, so we introduced saying "no" earlier.

Subdomain matches

Suppose you have a login saved with the host of paypal.com. Should 1Password help you fill that in when you visit www.paypal.com? What about the other way around? The "www" is a subdomain of paypal.com, and we have to decide whether our matching rules consider that a match. What about accounts.paypal.com? You are probably thinking that the answer is "yes".

The authors of the paper thought "no". The danger is with something like hacker.sites.google.com. Anyone can (or could, I'm not sure how this works now-a-days) set up a subdomain of sites.google.com with their own login page. You don't want your Google password going to the owner of hacker.sites.google.com.

And then there are thinks like students.poppleton.ac.uk Does each student get to set up their own pages potentially with forms under that domain? And so should 1Password fill in a password that you have saved for library.poppleton.ac.uk?

Note that there is a security/security trade-off in being too strict about these. If we don't match legitimate cases of subdomains, we end up encouraging people to copy/paste instead of using 1Password's auto-fill. But encouraging people to copy/paste increases other phishing risks.

So the answer to what we should do is that we do our best, trying to develop rules that 1Password can follow and get it right almost all of the time. But getting that tuned best involves a great deal of individual judgement and maintenance. For things like sites.google.com, we have a list of such domains to make use of. But not all of those cases are on that list.

URL mismatches

This is the most interesting of the problems raised. The problem, back in 2017 is that on Android the way that password managers integrated with other apps didn't give us a way to know that an app is associated with a domain. So suppose you have the Twitter app on your Android phone. When it interacts with 1Password for helping you sign into the app with your Twitter username and password, the app would tell the password manager that it wants the password for twitter.com. Should 1Password believe the app that it has the right to the twitter password?

Now imagine that the app presents itself to the user as some free little game, but it still wants a log in. When it talks to 1Password it might say that it wants the password for twitter.com. The user may not know that the app is asking for a twitter password. What 1Password does is make it clear to the user what password is being provided.

We have always been more cautious about this than some other password managers.

However, for reasons that I don't feel like digging into three years after the fact, the authors of the paper didn't agree that we were significantly better than our competitors in this. Our retention policy on email through our support system means that I no longer have a record of that conversation with the researchers. I could look through our bug/issue tracking system for about that time to see what we may have said then. Other, slightly more recent research, really liked how we presented this to users.

A more recent paper on this problem from 2018 pointed out that 1Password does not accept the recommendation of the app unless some other trust mechanism is there. That is, at that time we did no matching when filling for apps. Here is slide 15 from their slide deck

You might be interested to see what other password managers were doing at the time.

Progress

For this problem, 1Password (and other password managers) are being asked to match domains but with no control over how trustworthy the request is. So we chose to completely distrust (and largely ignore) the domain specification. That isn't an ideal situation. People do want 1Password to help find the best fit. Fortunately Android is offering tools to make it easier for apps to provably associate themselves with particular domains for exactly this sort of matching. This has been a feature of iOS for a much longer time, and so it will take time for Android app developers to catch up. But the tools are becoming more widely available. So Android app developers who make use of DAL will find that 1Password will match their domains nicely, with no scary warnings, as we will be able to trust that we have the correct domain associated with the app that is asking for log in information.