The right way to build reliable systems is to put all your eggs in one basket, after making sure that you’ve built a really good basket.
When you use a password manager, you are putting a great deal of valuable and sensitive information in one place. The expression, putting all your eggs in one basket is apt. When you put all your very valuable eggs in one basket, it is absolutely fit and proper to ask how secure that basket is.
The question becomes more salient when there are press reports of past security problems in a number of password managers (1Password was not among them). Those reports are based on some excellent research on web-based password managers by Zhiwei Li and his colleagues at the University of California, Berkeley, (“Go Cal!”).
What does that report mean for 1Password?
The Berkeley team looked at threats that affect web-based password managers. 1Password is not a web-based password manager and so, by and large, is not subject to the threats discussed in that paper. Different security architectures face different threats.
We made our choice of security architecture with this in mind. As a consequence of our design decisions, the particular threats and vulnerabilities discussed in the Berkeley paper are simply not applicable to 1Password.
(Most) Vendors acted swiftly and responsibly
Before I elaborate on some of the distinctions between web-based password managers, I would like to emphasize a point that I feel has not been sufficiently stressed in the public discussion of the Berkeley team’s analysis. The problems were fixed almost a year ago and apparently before any damage was done.
Although some of the problems were severe, four out of the five products studied fixed the problems quickly:
We reported all the attacks discussed below to the software vendors affected in the last week of August 2013. Four out of the five vendors responded within a week of our report, […] Aside from linkability vulnerabilities and those found in [the one that didn’t respond], all other bugs that we describe in the paper have been fixed by vendors within days after disclosure.
There is no denying that some of the disclosed bugs were severe, but they were reported responsibly and acted on promptly. Both the vendors and the researchers should be commended for how they handled this.
Because of its distinct security architecture, 1Password doesn’t face the specific threats in that particularly study, though it does face other threats which we try to defend against. Anyone who claims that they are completely invulnerable and bug free shouldn’t be in the security business. We strive to be bug free, and we strive for a fully secure design, but part of the process of security is making improvements in response to external discoveries of problems.
If I may quote something we wrote three years ago:
If you build a tough lock on a door, it is easy to imagine that you have now secured that door and don’t need to think about it anymore. But in the security business life is rarely that simple. Both the “threat landscape” and our understanding of the locks we’ve built earlier changes. The renowned security expert, Bruce Schneier is famous for (among other things) saying more than a decade ago that security is a process, not a product.
I am not trying to diminish the severity of the bugs discovered and fixed. They were anything but “routine”, but this case is an example where responsible disclosure and appropriate action kept user data safe.
Not Applicable
As I said above, 1Password is not a web-based password manager. You do not log into some web service that is managing your passwords. As a consequence, we don’t face the same kinds of security concerns that web-based services may face. A partial exception to that involves our 1PasswordAnywhere features, which I will return to below.
Nothing is impenetrable, but we have chosen a different security design deliberately. Our security design reduces the number of fronts on which we need to fight to defend your data. In slightly more technical jargon, we designed 1Password to minimize the “attack surface.” Let me run through a couple of examples of what I mean by certain sorts of threats not being applicable to 1Password.
With no authentication, no authentication errors are possible
One type of error discussed in the paper has to do with how the user authenticates (logs into) the particular web service. There are opportunities for bugs or design flaws to be introduced in that process. 1Password does not involve any authentication or web-based service, and therefore this isn’t a part of 1Password (at all) and so isn’t a part that can go wrong.
We can’t hand out data we don’t have
Another issue that came up in the Berkeley analysis of several of those web-based password managers is with how the service could be tricked into handing out data to the wrong person. Again, we don’t have your data in any form whatsoever, so even if we could be tricked into handing it out, we’ve got nothing to hand out.
Fewer phishing opportunities
Phishing is the trick where an attacker lure you into entering a password (or secret) that you would wish to give one service into a service under the attacker’s control. For example, most of us have received spam claiming to be from PayPal asking us to log in to reset our PayPal passwords. The actual website this spam directs you to is not the real PayPal site, but instead is something under the attacker’s control. This, for some reason, is called “phishing.”
You never type your 1Password Master Password into the web browser (with the exception of 1PasswordAnywhere). With 1Password 4, you never type your Master Password into a browser extension, either. You only type it into the 1Password program itself or into 1Password Mini (on Mac) or 1Password Helper (on Windows). Because of this, it is very unlikely that a malicious website could trick you into giving it your Master Password.
This is a consequence of the fact that 1Password doesn’t do authentication, but it is distinct enough that I listed it separately.
Goodbye to bookmarklets
Browser extensions and browser bookmarklets live in a hostile environment. They live in an environment that is partially created by the web pages you happen to be visiting (and things that those web pages may load from elsewhere). Browser extensions are sandboxed in a way that gives them more protection than bookmarklets. Bookmarklets are highly exposed, and so they need very very strong defenses.
Years ago, 1Password did offer a bookmarklet to provide some ability to use your 1Password data within browsers that didn’t support the 1Password extension at the time. But in 2011 we phased it out, saying:
It’s time to say good-bye to a couple of features that won’t stand up to the anticipated threat environment. One feature, loved by many, is the Login Bookmarklet. This was originally designed as a way to get some 1Password functionality into browsers we didn’t support at the time. Before we had 1Password for iOS, this could be used to kinda-sorta get 1Password data into browsers that didn’t support 1Password directly.
The data in the 1Password Bookmarklet is very well encrypted, but the password for it is not secured using PBKDF2. This means that if the Bookmarklet were to be captured it would need a very strong password on it to resist attack. Because the Login Bookmarklet lives in the browser’s bookmarks, there are more opportunities for it to be captured. Given these two issues, it is time to phase the bookmarklet out.
We weren’t saying back then in 2011 or saying now that it would be impossible to find a way to keep the bookmarklet both usable and sufficiently secure. But we were in a position, given our security architecture, to withdraw from having to defend your data on that particular front.
Linkability
Li’s team raised concerns about “linkability”. Linkability isn’t about revealing the content of your data, but it is a threat to your ability to remain anonymous. If you have a Login with username “Alice” on one site, and “Bob” on another, you may not wish those sites to be able to figure out that those two accounts belong to the same person. That is, you may not wish anyone to be able to “link” those two accounts.
1Password leaks no such information. We don’t have the ability to link those, and even someone who captured your encrypted 1Password data (new format) wouldn’t be able to perform such linking. Again, this is largely a consequence of the fact that we don’t store your data in any form.
Does anything in that paper apply to us?
From the above, you could be left with the feeling that there is nothing for us to learn from Li et al.’s paper. But there are lessons for us. We do have a browser extension, and while it is very different from the kinds of extensions used by web-based password managers, it still needs to remain secure in a hostile environment.
The paper offers two general recommendations that would help provide layers of defense for bookmarklets and extensions. One of them is to specify a restrictive Content Security Policy (CSP) within the extension. The other is to restrict what sorts of JavaScript language features are used within the extension or bookmarklet.
Good advice on Content Security Policies
Content Security Policies is a relatively new and not fully standardized technology. It is most useful for websites to state a CSP which browsers should then enforce. But it is also possible for browser extensions to state a policy. One important policy statement could say that no scripts from outside of the extension should be loaded. When CSP was first introduced, We had jumped on this but found that each browser did things differently, and at the time, even the most advanced didn’t behave as documented.
Here is an excerpt of something I wrote to some of the authors of the paper last Friday (July 11).
Our earlier attempts to specify a CSP within our [1Password version 3] extension left us with a bad taste in our mouth, but that was a few years ago and browser implementation was erratic, particularly of CSPs within extensions. Your paper is a nice reminder to attempt this again
We do currently use the default CSP that comes with Google Chrome’s manifest version 2 specification, but it is time to test again how well CSPs work in other browsers.
Defensive JavaScript
Zhiwei and co-authors also point developers to Defensive JavaScript. Roughly speaking this involves avoiding certain features of the JavaScript language, while at the same time encapsulating your own JavaScript functions to protect them from outside tampering.
We had already been aware of the specific recommendations. Although we may not be following the letter of those recommendations, our practices have long been in line with the spirit of them. We avoid “eval”-like operations, and anything we inject into the web page is wrapped up in closures.
Again, their paper is a nice reminder for us to take a look at this again, to ensure that we are doing everything we can to protect our browser extension from compromise.
The exceptional 1PasswordAnywhere
1PasswordAnywhere is an optional, but useful, feature for many users of 1Password. It is useful when you don’t have 1Password itself with you. If you synchronize your data with Dropbox using the Agile Keychain Format, you will have a file within your Agile Keychain folder called 1Password.html. That file contains the JavaScript necessary to give you read access to your 1Password data stored on Dropbox in your Agile Keychain.
1PasswordAnywhere is as secure today as the day we introduced it. Its security has not diminished in any way. But it does remain an exception to much of what I have said above. It does involve a great deal of cryptography in JavaScript; it is an instance where you do enter your 1Password Master Password into the browser, its security relies on TLS/SSL in a way that the rest of 1Password does not, and it is subject to active attacks (data tampering) in ways that the latest version of 1Password is not.
Again, let me stress that 1PasswordAnywhere remains as secure as ever. But because it is cryptography in JavaScript delivered over SSL/TLS and stored on a third party system, it faces threats that other uses of 1Password do not face.
Continuing the discussion
Zhiwei Li will be presenting his results at the 23rd USENIX Security Symposium August 20–25, which I will be attending. I am very much looking forward to continuing my discussion with him and his co-authors in person. I will have a busy August. I will be presenting a paper at PasswordsCon14 August 5–6. In between these two conferences is my 25th wedding anniversary. (If LĂvia can put up with me talking about security concepts for 25 years, you, Dear Reader, can manage to wade through some of my long-winded explanations on occasion.)
Baskets are inevitable
I would like to return to the concerns about “putting all of your eggs in one basket”. With a password manager, you are, indeed, putting all of your eggs in one basket. And so it is important that you read articles like this so that you can get a better sense of how well that basket is protected. But I would like to point out that the likely alternative to using a password manager is to resue passwords. Reusing passwords involves putting multiple eggs into multiple, very fragile baskets.
Password reuse
Regular readers of the Agile Blog know that I can’t avoid speaking of the dangers of password reuse. When you use the same password on more than one site or service you are putting yourself at risk. A breach of security with one of those sites leads to your password being discovered, allowing attackers to compromise all the other services for which you use the same password.
Reuse baskets
Suppose that you use the password “2b|kn0t2b” on five different sites. Say, PayPal, Amazon, Dropbox, MyKittyPictures, and TheNewBarkTimes. By doing so, you are putting the security of those five eggs into a single basket. Sure, that isn’t all your eggs in one basket, but it is still five. The more you reuse a password the larger the basket grows.
Furthermore, the bigger your reuse basket grows, the weaker it becomes. This is because the more sites and services that you use the same password for, the more likely it is that that password will be exposed. Suppose that one of the sites doesn’t use SSL/TLS to security your connection. Your password for that site (and for the whole basket) will travel over the network unencrypted. Suppose another site suffers a breach in which its (hopefully hashed) password database is stolen. Your password for your whole basket will depend on the strength of the password and how well that particular site hashes the password. Perhaps one of the sites that you use that same password for is in the habit of sending passwords through email (it happens). The larger your reuse basket becomes, the greater the opportunity for it to be compromised.
So far, I have met one person with many logins who does not need to put multiple eggs into a single basket. She credibly claims to have memorized about 80 unique and reasonably secure passwords. Her superpower is a photographic memory and specific security training in password choice. The rest of us, however, do not share her superpower, and inevitably must put multiple eggs into single baskets. It’s better to pick a basket like 1Password that has been carefully designed for the purpose and subject to scrutiny.
Jeffrey Goldberg
Principal Security Architect
Tweet about this post