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

"Researchers expose vulnerabilities of password managers":


Unfortunately this article is very vague.

I have seen posts on this forum that people which forget their password can try as many times as they want, so no limit (as mentioned as a weakness in this article). However, I don't think 1Password uses a PIN (only a Master Password) on desktop platforms. In fact, the article does not even mention on which platforms this happens...

Is 1Password affected?

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided


  • BenBen AWS Team

    Team Member

    1Password for Mac and 1Password for Windows do not utilize a PIN. Beyond that, I'll reach out to our security team to see if they know more about the specific research this article is referencing.



  • LarsLars Junior Member

    Team Member
    edited March 17

    @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.

  • Thanks.

    Didn’t notice before that they actually offered a link to their research...

  • BenBen AWS Team

    Team Member

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


  • edited March 21

    Thank you for your response, Ben and Lars, about the vulnerability to brute-force attacks on the master password. Your response seems sensible.

    In reading the paper I was more concerned about the reported vulnerabilities to phishing. The paper called out the following specific vulnerabilities:

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

    What is 1Password's position on these vulnerabilities?


  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    edited March 22

    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.1

    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".2 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

    1Password for Android warning when matching

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


    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.

    1. 1Password cannot really protect you from copying the password and pasting it in to a phishing site. But 1Password will not fill the thing in for you, and by refusing to do so, it makes it much easier for you to see that you might be trying to copy a password to the wrong site. ↩︎

    2. I am going to ignore the port portion of the URL for this discussion. ↩︎

  • Thank for the timely and comprehensive reply! My concern has been addressed.



  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    edited March 22

    Thank you everyone.

    If I may get a bit more meta (and vent a few frustrations) there are some other things that we learn from this.

    1. Any news reporting "vulnerabilities" in password managers is likely to gain traction. The more dramatic the title, the more likely it is to garner clicks.
    2. University press offices are not immune to publishing highly misleading press releases.
    3. Not all journalists read the actual paper but instead rely on the press release and quote a few figures
    4. Many security/security trade-offs are made in designing something like a password manager. It's easy to critic one side of the trade-off without recognizing the other.

    I really do value academic and security community research on this kind of thing. I'm please that it was done, and I hope that more will be done. But often they "discover" things that we've known about for a long time and had to make choices about. The example of how strict subdomain matching should be compared to the risks of more copy/paste is a good example.

    A separate security/security example

    Another example of a security/security trade-off (not in this particular research) is biometric unlock. Biometric unlock on your mobile device is not "as secure" as using your master password in some regards. But it also improves security by enabling people to use stronger master passwords than they otherwise might and to reduce opportunities for shoulder surfing. So when designing our system, we have to tune our settings and defaults.

    What this will sometimes mean is that one week someone will write about the the weaknesses of biometric versus password unlock and scold us for allowing biometric unlock. The next week someone else will write about shoulder surfing and scold us for not going to more biometric unlock. And on any given week we have no idea of what will gain traction.


    So I love that people are doing the research. And I love that people are reporting on it. But at the same time, I often find myself highly frustrated by the way the research is originally presented and reported on. This latest thing is particularly egregious given that most of the headlines talk about "new" vulnerabilities while the actual paper describes them being addressed in 2017.

    On the other hand, it gave me the opportunity to describe our thinking on the issues. And I love doing that.

  • Thank you for your explanation!

    Note that there is a security/security trade-off

    You wrote that a couple of times; I’m familiar with the term “convenience/security trade-off”, but what do you mean when you have security on both sides?

  • ag_anaag_ana

    Team Member


    jpgoldberg wrote an additional example about this in his latest post above yours, in the section A separate security/security example.

    Does that help clarify things?

  • Yes; reading that again I think I understand it now.

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Hi @XIII

    Sorry if I didn't explain the concept well. But let me give some other examples of security/security tradeoffs.

    The Secret Key: Data Confidentiality vs Data Availability

    One of the simplest examples of a security/security trade-off is 1Password's Secret Key. It does a really important job at protecting your data confidentiality, but it increases the risk of to availability. (Data availability is also part of data security.)

    It improves data confidentiality by making the data that we host uncrackable, but it also increases the chances that you will be locked out of your own data, thus it increases the threat to data availability. We choose to accept a higher risk to data availability for the reduced risk to confidentiality. That makes it a security/security trade-off

    Laptops with air passengers or in checked luggage

    A while back, a plot was discovered to get something nefarious (the public was never told what) into aircraft in laptop computers. And very briefly there was a plan to require people to put laptops and tablets into checked baggage. That was a truly terrible idea and fortunately it got reversed quickly. Electronics with dense batteries occasionally catch fire on their own. It is far far safer to have that happen in the passenger cabin (where it can be quickly spotted and dealt with) than in checked baggage. So that is a safety/safety trade-off. We choose to allow for an increased risk of bad people being able to bring bad stuff into the passenger cabin with them in order to reduce the risk of accidental fires in the luggage compartment.

    Hard and easy choices

    Many of these choices are easy. (I was amazed that forcing laptops into checked luggage was even considered, but people making those sorts of decisions had access to more information than I did. Still, I suspect that they hadn't considered the accidental fire risk, which is why the policy was so quickly reversed.) Or seatbelts save thousands of lives per day, while the do introduce a small risk of being trapped in a vehicle. Again, that is a really easy choice where the security gain in the trade-off is far far larger than the risk it adds.

    But some choices are harder. Exactly how picky we should be on domain matching, as in what I'd originally described, is harder. Too loose matching and we increase the risk that 1Password will fill something in the wrong place. Too tight and we force people to copy/paste passwords more often putting them at risk of phishing in other respects. Working in security means recognizing these sorts of choices. It is interesting work.

  • Can 1Password provide some commentary on the recent research paper which indicates it is susceptible to automatically filling in credentials on incorrect websites and illegitimate apps?

    Link to article.

    1Password Version: Not Provided
    Extension Version: Not Provided
    OS Version: Not Provided
    Sync Type: Not Provided

  • ag_anaag_ana

    Team Member


    I have merged your post with this existing discussion. Please see above for the answers from our security team.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file