Shellshock is bad, unique passwords are good

Shellshock bash terminalA new security bug, commonly known as Shellshock (Officially CVE-2014-6271, is bad. It is fair to say that a large number of servers (particularly web servers) were vulnerable to serious attack for some time. It is likely that many still are, and we are unlikely to learn about most of them.

What are we do to? Answer: Use unique passwords for each site and service.

Squirrels, rabbits, and passwords

Squirrel mollyLet’s consider Molly, one of my dogs. She has a one track mind: Squirrels and rabbits. She also is not very good at counting, so she doesn’t understand the difference between one track and two tracks.

Molly tends to reuse the same password for lots of things. Her password for Barkbook is squirrel. It’s also the password for CatChasers and a number of other sites and services.

Suppose that Patty, my other dog, isn’t the sweet innocent little thing that she pretends to be. Suppose that she breaks into CatChasers and is able to steal user passwords from it. She learns that Molly’s password was “squirrel” on CatChasers, so she’ll check if Molly used the same password on Barkbook and other sites.

1P squirrel password

Password reuse is doubly bad

Indeed, when Molly uses the password “squirrel” on multiple sites, she is putting all those squirrels in one basket. If her password is stolen on any one of those sites, Patty can get into all of those.

The more places that Molly uses the password “squirrel,” the more likely it is that at least one of that sites will get breached, and the more damage is done when her password gets discovered at any one of those sites.

If Molly uses “squirrel” for twenty sites, there is a very strong chance that several of them are vulnerable to this new Shellshock flaw, Heartbleed, or any of the other known and unknown vulnerabilities being exploited. When Patty does break into one of those twenty sites, she will now have control of twenty of Molly’s accounts.

What you can do

In short, be careful. System administrators will be busy for a while. In addition to upgrading bash on systems that use it, they should be trying to track down which systems create environment variables with untrusted content and whether those systems ever invoke a shell.

But normal people (and I don’t think that many will dispute that system administrators are not “normal people”) are left with the knowledge that there are a lot of vulnerable systems out there. By far, the single best things we can do is to cut down on our password reuse. The easiest way to do that with 1Password is to give Security Audit a whirl.

There is so much more to say

Everyone with some sort of security point to make is using Shellshock to help illustrate and draw their favorite lesson from it. This is easy to do because Shellshock isn’t just a bug, it is a bug that can be exploited because of a series of design decisions that were pretty much asking for trouble. Each one of those decisions (or non-decisions) is something that everyone in the business really does know better about. But somehow, the software and systems engineering community has managed to ignore its own wisdom at each step of the way.

  1. We members of this community know not to pass untrusted data to various other processes, yet we’ve allowed systems that create shell environment variables (things designed to be passed all over the place) from the most untrusted sources of all. [E.g. CGI, DHCP Clients, etc].
  2. Our community knows that tricking systems into executing “data” is often how attacks happen, yet bash has a feature that deliberately allows what is normally data passed around to be executed.
  3. Whether computer science students like it or not they are taught that when data is in a particular class of languages it is impossible to validate it, yet with bash we’ve stuck a Type 0 languages inside of variables.
  4. Scripts and programs should (generally) avoid invoking a shell as even the Linux manual page for system(3) says

    Do not use system() from a program with set-user-ID or set-group-ID privileges, because strange values for some environment variables might be used to subvert system integrity.

    Yet calling system(3) is common practice because it is easier than invoking other programs the proper way.

When a system falls victim to Shellshock, it is because every one of those principles and guidelines have been ignored. The first one is in the design of various network services (such as web servers). Numbers two and three are in the design of bash, and number four crops up in innumerable scripts and programs. None of them are actually about the specific bug in bash. Instead, one through three are about specific design features of various systems.

There is a great deal I would like to say about each of these, but I will leave that ranting for another time. Today, I just wish to remind everyone about the importance of using unique passwords for each and every service.

Bash update for Mac OS X

Apple has made bash updates available to those who do not wish to wait
for regular software update:

OS X bash Update 1.0 may be obtained from the following webpages:
http://support.apple.com/kb/DL1767 – OS X Lion
http://support.apple.com/kb/DL1768 – OS X Mountain Lion
http://support.apple.com/kb/DL1769 – OS X MavericksTo check that bash has been updated:* Open Terminal
* Execute this command:
bash --version
* The version after applying this update will be:
OS X Mavericks:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13)
OS X Mountain Lion:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin12)
OS X Lion:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin11)

Watch what you type: 1Password’s defenses against keystroke loggers

1Password for WindowsI have said it before, and I’ll say it again: 1Password and Knox cannot provide complete protection against a compromised operating system. There is a saying (for which I cannot find a source), “Once an attacker has broken into your computer [and obtained root privileges], it is no longer your computer.” So in principle, there is nothing that 1Password can do to protect you if your computer is compromised.

In practice, however, there are steps we can and do take which dramatically reduce the chances that some malware running on your computer, particularly keystroke loggers, could capture your Master Password.

Safe at rest

Let me clarify one thing before going on. 1Password does protect you from the attacker who breaks into your computer and steals your 1Password data. The 1Password data format is designed with just such attacks in mind. This is why your data is encrypted with keys derived from your Master Password. It is also why we’ve put in measures to make it much harder for an attacker to try to guess your Master Password in the event that they do capture your data.

Even if an attacker gains access to your computer and 1Password data, there is little she can do without your Master Password. In this article, I’m focusing on another kind of attack in which the attacker tries to “listen in” to you typing your Master Password. This attacker is running a program on your computer that attempts to record everything you type on the keyboard or enter through some sort of keyboard-like device.

Countering counter-counter measures

I will get to the details below, but this article aims to describe and explain a change in how 1Password for Windows secures its Secure Desktop, a counter measure against a common type of keystroke logger. This change was added recently to 1Password 1 for Windows and has been included in 1Password 4 for Windows since its launch.

Márcio Almeida de Macêdo and Bruno Gonçalves de Oliveira of Trustwave SpiderLabs have discovered a way that a keystroke logger could work around our use of Secure Desktop and reported this to us. They have now reported this publicly (link might be having trouble, but it’s listed among their Security Advisories). We have since added a mechanism which prevents that particular counter measure to Secure Desktop. We very much appreciate SpiderLabs for giving us the opportunity to put a fix in place before announcing their discovery to the public. Trustwave SpiderLabs might grab fewer headlines by having done the right thing, but they have done the right thing.

Secure Desktop itself is a counter measure to keystroke loggers. De Macêdo and de Oliveira’s discovery is a counter measure to our counter measure. We have now introduced a counter-counter-counter measure. All of this will be explained, but it requires a lot of background into how keystroke loggers work and various ways to defend against them.

Keystroke loggers

Keystroke loggers attempt to capture everything that is typed on a particular computer or keyboard and pass that information on to a third party.

There are one or two legitimate uses of these (such as in research on writing), but those all involve the consent of those whose key strokes are being logged. More typically, keystroke loggers run surreptitiously, and are an attack on user privacy. I know that people don’t come to this blog for relationship advice, but if you are seriously tempted to install a keystroke logger to spy on a spouse or lover – a popular use of these things – then I have my doubts about the future of your relationship. Since you didn’t come here for relationship advice (and if you did you came to the wrong place), let’s return to how keystroke loggers work.

Logger in the middle

There are many different ways that keystroke loggers can work, but one useful way to think about this is as something (either hardware or software) that sits between your keyboard and the program you are typing into, something which shouldn’t be there.Hardware PS/2 keylogger in action

For keyboards that are attached to a computer with a cable, the simplest keystroke loggers are little physical devices that the attacker plugs into the computer, and then plugs the keyboard cable into that.

The keystroke logger is, in this case, sitting between the keyboard and the computer. The computer thinks it is talking directly to the keyboard, and the keyboard thinks it is talking to the computer, but the keystroke logger is sitting between them.

Alternatively, software keystroke loggers sit between components deep within the operating system and silently grab data. Things that are embedded that deeply or are using hardware loggers are not things that user software can detect or defend against.

Most keystroke logging is shallow

Most keystroke loggers take a simpler approach, rather than inserting themselves deep within the system. It is much simpler to write a program that says “hey, I am a program that needs to know everything that is coming in from the keyboard.” Operating systems provide hooks for programs to do exactly that.

You might be asking why operating systems might make writing keystroke loggers so easy. What business does any program running in the background have in seeing the input to some other program? One reason is to help my poor dog Molly, who suffers from (among other things) diabetes. This has led to sufficient necrosis in her paws so that she cannot easily type using a standard keyboard. The specialized device that she uses involves some clever software that looks at the input and uses various predictive technologies to replace the actual input with the intended text. This system intercepts (and changes) input bound for any program running on her computer; however, as far as most programs know, they are just getting input from a “keyboard”. Assistive technologies similar to the one Molly uses are a big part of making computing and communication accessible to more people.

Not only is a basic keystorke logger easy to write, it doesn’t require a complete break into a system. Different processes on a computer run with different privileges. When Molly logs in to her account and runs a program on a computer, the program is run under her user ID and with her privileges. This means that she isn’t able to interfere with processes that are run by Patty (the other dog). She also isn’t able to interfere with the system as a whole. If Mr Talk (the neighbor’s cat) tricks Molly into running a malicious program, that malware will be limited in the damage it can do.

The really deep and hard-to-avoid keystroke loggers would require full power over the system to install. But one of these simpler keystroke loggers requires only the privileges of the user whose keystrokes are to be recorded. So if Molly gets tricked into running a keystroke logger, it won’t affect Patty even if they use the same computer (as long as they are using different accounts). As you can imagine, the bulk of malicious keystroke loggers that spread through computer infection are of this shallower sort.

Counter measures

Now that we have some idea of how the typical keystroke logger works, it’s time to look at some counter-measures. The two most important counter-measures are:

  • keep your system and software up to date
  • exercise caution in what software you install and run

But let me focus a couple of the counter-measures that 1Password takes.

Counter measures on Mac: Secure Input

On Mac OS X, there are two simple provisions that makes it easy to thwart those shallow key loggers. The first one of these is called “Secure Input” and was introduced with OS X 10.3 Panther in 2003. A program—1Password for example—can say, “when the user types something into this particular input field, it must be done in a way that other processes can’t interfere.” Secure Input needs to be used sparingly, as it blocks all of the sorts legitimate activity, including assistive technologies that many people (and a few dogs) rely on. And Secure Input blocks TextExpander, which I rely on.

1Password declares the field in which you type your Master Password as a “Secure Input field”, then ordinary key loggers won’t have access to it. Since last year’s OS X 10.9 Mavericks, there is another defense built into the operating system. A program can only capture all of a users’ keystrokes if the user has explicitly granted it that permission in System Preferences > Security & Privacy > Privacy under Accessibility. As I described earlier, most (but not all) such software are components of assistive technologies designed to make computers accessible to more people. That is why this system preference is ultimately under Accessibility.

Between these two mechanisms – Secure Input and that any application which has the capacity to log keystrokes must have explicit user approval to do so – OS X defends against these otherwise common sorts of keystroke loggers.

Counter measures on Windows: Secure Desktop

1P Win unlock secure desktop

Windows doesn’t offer the same sorts of defenses that OS X has, but it does allow for the creation of somewhat isolated environments called “Desktops”. On Windows, one can set up different Desktops in which only your program is running (along with system processes). A program running in one Desktop will not be able to listen in on keyboard input in a separate Desktop.

You will find a button that says “Unlock with Secure Desktop” in the upper right corner of the lock screen in 1Password 4. Clicking on that launches the Secure Desktop in which you will be prompted for your Master Password. You can take a look at Unlock with Secure Desktop in action.

Countering Secure Desktop

What de Macêdo and de Oliveira have discovered is that there is a way to set up a keystroke logger that does operate in all desktops, not just the one it was started in. Quite simply, their system launches a process that is able to listen for the creation of new desktops and add a process to each desktop created.

The ease at which they were able to do this (well, everything looks easy in retrospect) reflects the fact that the SwitchDesktop function in Windows was not designed for security purposes. We and others who use Secure Desktop as a mechanism for evading keystroke loggers have been taking advantage of the relatively isolated environment of a separate Desktop. Once the authors of keystroke loggers take our counter measures into account, they can launch counter-counter measures like the one Trustwave describes.

Knowing your environment

We want nothing but system processes and 1Password’s Master Password entry to be running in a Secure Desktop. We don’t want other, probably malicious, processes joining that Desktop. And so, our counter-counter-counter measure is to simply look around and see if there is anything running in the SecureDesktop that is unexpected.

If some unexpected process is found in the Secure Desktop environment, you’ll be prompted to close the Secure Desktop.

Secure Desktop: 1Password has detected an unknown process

Lessons

1. Keep your system and software up to date

The single biggest thing you can do for your computer security is to keep your system and
software up to date. The overwhelming majority of actual break-ins are through vulnerabilities that have already been fixed by the software vendors.

2. Pay attention to what software you install and where you get it from

Keystroke loggers and other malware are often installed unwittingly by the victims themselves. Try not to be one of those victims. Be particularly careful of anything that tries to frighten you into installing it. Fake security software and alerts are a common way to get people to install malicious software.

The move toward curated app stores offers additional protections, but it isn’t a complete solution. Still, using those where available will reduce your risks.

3. Use Windows Defender on Windows

I have long been skeptical of most anti-virus software, but Microsoft Security Essentials is something I can unequivocally recommend for those using Windows 7. In Windows 8, Windows Defender is automatically built in and enabled.

4. Understand what software can and can’t do for you

The core security design of 1Password is extremely strong. Quite simply: if you have a good Master Password, nobody who gets a copy of  your 1Password data will be able to decrypt it. 1Password can and does offer outstanding security.

At the same time, 1Password is limited in what it can do to protect you when you are using a compromised computer. It can (and does) offer some protection against shallow (the most common) attacks. But this is a bit of an arms race. As you see, we have had to put into place a counter measure to a counter measure to our counter measure against common keystroke loggers.

This is why the first two items on this list are so important.

In conclusion

1Password takes extraordinary and effective steps to protect your data. This is built into every aspect of its design. But you have to help protect 1Password from malware running on your machine. We do what we can to make things harder for the malware writers, but we can’t do it alone. You must try to provide a safe environment for 1Password and all of your software to run in.

This shared responsibility is similar to that which we have with your Master Password. We provide excellent encryption and protections and defenses against automated password guessing. But you have to pick a good Master Password and treat it well. For those who might be wondering, displaying your password on a giant screen is not treating a password well.

wold-cup-wifi

Heads up: Your best defense against the Russian hacker data breach is still strong, unique passwords

The bad news: Russian hackers claim to have gotten their hands on a sizeable collection of login credentials and emails.

The semi-good news: the story might not add up. According to The Verge, most, if not all, the credentials may simply have been collected from previous breaches we already knew about, including Adobe, LinkedIn, and others.

The good news: strong, unique passwords for all your sites are still your best defense. If shady individuals nab one or even more of your accounts, 1Password’s unique passwords prevent them from using that information to break into all your accounts.

Unfortunately, we live in a world where data breaches are going to happen. As my colleague Jeff Goldberg likes to remind us: security is a process, not a destination.

Strong Password Generator hero

The best way to defend against breaches large and small is the same as it ever was: use 1Password’s Strong Password Generator on Mac, Windows, and iOS to create strong, unique passwords for all your accounts with a single click.

1Password’s Security Audit feature is also a great way to stay on top of your security. It shows you duplicate and weak passwords, and our built-in 1Password Watchtower service warns you to change your passwords for any of your Login’s sites that have recently been breached.

As usual, the headlines sound big, but the solution is simple. Use 1Password’s Strong Password Generator for the best defense against data breaches. As this matter is examined further, we’ll let you know more about breach sources or any other pertinent details.

1Password is a very safe basket

—–
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 [strong] 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.

No, you do not need to change passwords in response to the OpenSSL CCS bugs

For the third time this year, there is yet another flaw in an underlying security technology used across the net: the recently fixed OpenSSL bugs announced on June 5. For our customers, we are happy to report that 1Password is not affected by bugs in SSL implementations, nor do these bugs require that most people change passwords.

1Password is not affected and your data remains secure, and you do not need to make password changes. The bug that everyone is talking about, lovingly referred to as “ChangeCipherSpec (CCS)” (also known as “CVE-2014-0224″ or “SSL/TLS MITM vulnerability”), is not in the same category as the recent, catastrophic Heartbleed. It does not require a response from most people in the way that Heartbleed did.

Why no password changes?

As bad as the CCS bug is, here is what makes it different from Heartbleed from a user’s perspective.

1. The attacker must be in a “privileged network position”

Not anyone can launch a CCS-based attack. The attacker must be the operator of some of the network between you and the site you are using. In this respect, the attack is similar to the GotoFail bug in February on Apple’s Secure Transport. In contrast, Heartbleed could be easily launched by anyone anywhere on the net.

2. Both the client and the server must be vulnerable for the attack to work

This means that if you are not using a vulnerable SSL client (web browser, email program, etc), then you remain safe from this attack even if the server is vulnerable. Few desktop browsers use the OpenSSL libraries to manage their SSL connections. Chrome on Android and Konqueror on KDE (linux) are the two most popular ones I can think of that do. Chrome on desktops does not use OpenSSL. In contract, Heartbleed only required the server to be vulnerable.

3. Many systems were fixed before the news of the bugs were made fully public

It is very tricky to fix a bug in open source software without making knowledge of the bug public at the same time. The OpenSSL team and the discoverers of Heartbleed attempted, but failed, to get most systems fixed before going public. With these bugs, they did a better job, so the window of vulnerability was much shorter.

Each of the first two reasons, on their own, are sufficient for me to conclude that the large majority of people do not need to worry about changing passwords. The combination of them and the other two make me extremely comfortable in this advice.

If you are concerned about governments or network operators having exploited this bug, and if you used clients that relied on OpenSSL for their SSL operations (such as Chrome on Android or Konqueror and other KDE tools on Linux), you may wish to change those passwords. But most people don’t need to take any action. It remains important that you do change passwords for systems that had been vulnerable to the Heartbleed bug reported in April. With Heartbleed, there really is a wolf we are crying about.

These new OpenSSL bugs do mean that system administrators need to update their systems quickly, but it does not require them to rekey their server certificates. These bugs are substantial, but the response is the usual “upgrade affected systems promptly”.

Everything that follows goes into technical details explaining what the recent bugs are and what they may mean in general. They have no specific impact on 1Password, but I know that some of you are curious, and I do indeed suffer from a pathological compulsion to explain things.

Read more

Password reuse lands Find My iPhone users in expensive hot water

1Password 4 for Mac icon

There are plenty of examples as to why friends shouldn’t let friends reuse passwords, but some users of Apple’s Find my iPhone have become the latest omen of why this practice is so dangerous.

On Tuesday, May 27, The Verge reported that Apple’s Find my iPhone feature was being used to lock devices for ransom. Some people found their Mac or iPhone locked—a legitimate feature of Find my iPhone—with a message of “Device hacked by Oleg Pliss” and a demand of $50 to unlock it.

At first it wasn’t clear how the malicious hacker(s) were able to compromise these devices, but today Apple stated that it wasn’t through an iCloud flaw. The most likely culprit, then, would be password reuse. Thanks to all the recent major breaches at some of the internet’s largest companies, including eBay, Adobe, and Yahoo, the hackers probably had plenty of material to rummage through.

Let this be yet another unfortunate and pricey lesson about reusing passwords. Don’t do it. Don’t let your friends and family do it. Send them these stories and get 1Password to effortlessly create strong, unique passwords for all your accounts.

Introducing the 1Password Watchtower service for Heartbleed and beyond

1Password Watchtower

When news of the internet’s Heartbleed bug broke last week, we published what we knew about it and the implications for 1Password and 1Password users.

To recap: 1Password is not affected by Heartbleed, but there are steps you need to take to protect your passwords from sites that may have been affected.

Today, we’re introducing a new service to help you check vulnerable sites and stay on top of your online security. We call it 1Password Watchtower.

A way to check if the bleeding has stopped

Your password data remains safe and secure within 1Password, but when your web browser sends a password to an insecure website, that particular password can be captured.

Most, but not all, websites have had some period of being insecure because of Heartbleed, and this is why so many passwords need to be changed.

Since those first few hours on April 7, we’ve gone from “what is this all about?” to “which sites do I need to change my password, and when?” Today, the 1Password Watchtower service will help you answer that question.

1Password Watchtower: Check this website

The categories of sites

With respect to Heartbleed, the 1Password Watchtower service will try to categorize websites into one of the following five categories.

1. Vulnerable

SiteChecker vulnerable example

Sites that are still exhibiting the Heartbleed bug should be avoided until they’ve fixed it. Once fixed, you should change your password.

If you reused a password for one of these sites, then all of those websites are also at risk. You should change your passwords on those other websites as soon as appropriate, and be sure to set up a different password for each of these sites.

2. Not currently vulnerable but needs new certificate

SiteChecker Needs new certificate

This is where things get complicated. While these sites have stopped the bleeding, their master keys may have been stolen while the site was vulnerable.

To protect against this, websites need to get new certificates signed by certification authorities, which simply takes time (especially when nearly every site needs to do it). It took two days to get our new certificate, and I would not be surprised if others will have to wait longer, especially if they submitted their requests after us.

For these sites we recommend that you change your password twice. Changing your password now will prevent an attacker from using any previously stolen passwords. Then you can change your passwords again once the site’s certificates have been reissued to guarantee that the new password is only known by you.

3. Not currently vulnerable and has a new certificate

SiteChecker new certificate example

These sites were vulnerable to Heartbleed at one time but have been completely fixed. You can go ahead and change your passwords on these sites.

You may find yourself with many sites for which you need to change passwords, but don’t let yourself get overwhelmed. Focus on changing passwords for your most important websites first.

1Password can help you through the process, and of course, this is a great opportunity to use 1Password’s Strong Password Generator to create a strong and unique password for each site.

4. Never vulnerable

SiteChecker Never Vulnerable example

Some sites and services were never vulnerable to Heartbleed, typically because they never used OpenSSL or had disabled various features.

One piece of good news is that, as far as we can tell, most banks fall into this category. However, to the annoyance of security researchers, banks are not telling us why they weren’t vulnerable; they are merely repeating that their customers are and have been safe.

For  sites that were never vulnerable, no special action is needed. You do not need to change those passwords if your passwords were unique to those sites.

But (and you will hear us repeating this often) if you used the same password on a “never vulnerable” site that you used on one which was vulnerable, then you should change your passwords to be strong and unique on both sites.

This illustrates why password reuse on multiple sites is so dangerous. Even services that have had excellent security on their own can be broken into with a password stolen from elsewhere. 1Password’s Security Audit will help you find duplicate passwords.

5. No SSL/TLS

SiteChecker: No SSL

Sites in this category are in no way affected by Heartbleed, but these are the services where it is most important that you don’t reuse passwords.

Some sites and services do not use SSL/TLS to secure connections between your web browser and their service. Because they have no transport security to break, their security can’t be “broken” by Heartbleed. Any password—or, really, any data—sent to such a site can be easily captured. If you have a password for one of these sites, make sure that you don’t use the same password for any other service.

Subdomains matter: It is important to remember that 1Password Watchtower checks the exact domain you tested. So even if go.com doesn’t use SSL, subdomains such as disney.go.com, may. It does not appear that one ever sends passwords to go.com itself, so its lack of SSL does not put passwords at risk.

How do we know which sites fall into which category?

Sorting hatAs 1Password Watchtower checks for Heartbleed, it performs a number of tests on a domain and its certificate, as well as looking at the results of earlier tests. But even with all of the tests that we run, there is some substantial “guess work” in the categorization.

We can reliably tell which sites are currently vulnerable and which sites aren’t. We can also check the start date for the validity of a certificate. We run other tests, but whether they produce results or not, they only offer hints at which category we should put a domain into.

If you are a site administrator and find that we are reporting incorrect results for your site or service, please make use of Heartbleed HTTP Headers to announce your condition or let us know.

Uncertainties

Never vulnerable or needs a new certificate?

The biggest uncertainty is that we have no reliable way to distinguish between sites waiting for new certificates and sites which were never vulnerable. Both such sites will not be currently vulnerable and will not have new certificates. We look at fragmentary results of previous scans as well as web server software to try to form a guess, but it remains a guess.

Is an old certificate really old?

Every certificate has a validity period. They have a “valid from” date and a “expiry” date. We are (mostly) using the date from which they are valid to see if they are old or new. However many recently reissued certificates have the same validity period as the one that they replaced. As a consequence, certificates that appear as if they are in need of replacement aren’t.

Are we talking to the right service?

Many high traffic web sites use load balancers, which don’t actually process your web request, but send off your request to a one of many back-end servers. The software on a load balancer is meant to be invisible, but it will often be different than what appears on the backend. The tests we perform involve a number of queries, some of which will be handled by the back-end servers and some by the load-balancer. For example, a load-balancer that was running an affected version of OpenSSL might be using IIS as a back end, and thus we might false report as “never vulnerable”.

Wrapped Heartbeed Heart: Strong, Unique, New Passwords

Use strong, unique passwords and carry on

Heartbleed is an astonishingly serious thing, but it isn’t cause to panic. Indeed, frightened people tend to make poor security decisions. The bulk of the work is being done by system administrators, and there are changes to come in the ways critical software is scrutinized. But for most people like you and me, the job is to improve our password practices.

Many—I’d like to think nearly all—1Password users are good about having strong, unique passwords for each site and service. That habit should already make the current task easier for you. Heartbleed and this initial version of 1Password Watchtower gives you another opportunity to improve even more. Doing so will make you safer now and long into the future.

Heartbleed: Imagine no SSL encryption, it’s scary if you try

heartbleedOnly two months ago, in the wake of the “goto fail” bug, we had to point out that 1Password’s security does not depend on SSL/TLS. Today, with the far more damaging Heartbleed bug in OpenSSL, we need to tell you the same. 1Password’s technology is not built upon SSL/TLS in general, and not upon OpenSSL in particular. 1Password’s encryption remains safe.

This bug matters for everyone

Just because 1Password’s technology isn’t affected by this doesn’t mean that you aren’t. Pretty much everyone is affected by this. Many of the secure connections that you use with various services, including HTTPS connections to secure sites for shopping and many other activities, may be fully readable to attackers. Of course, this includes the usernames and passwords that you use to log in to various services. It’s not just HTTPS connections, but IMAPS—how your email program, such as Mail.app or Outlook, talks to a mail server—may be vulnerable.

“So I need to change all my login passwords, right?”

Your 1Password data remains safe, as does your 1Password Master Password. But whether or not you use 1Password to log into an affected site or service, your username and password, along with everything else that happens over that supposedly encrypted connection, may be exposed to attackers.

You will, at some point, need to change a lot of passwords. And 1Password makes this much easier than it other would be. But don’t rush to do that just yet. Not every server is affected, and those that are need to fix things at their end before you change your password. If you change your password before the servers fix things, then your new password will also be vulnerable to capture.

All that most of us can do is wait at this point. Presumably, various service providers will announce over the next few days when and whether users should change passwords or be aware that other confidential information may have been exposed.

Change password example

When changing your passwords, be sure to pick “Update existing Login” from 1Password’s prompt!

At this point, I can only guess at how long it will take for various service providers to make announcements. They are in a difficult position right now. First, they need to determine whether they are vulnerable. That means finding out if their particular SSL/TLS service was using OpenSSL (the most popular SSL library in use today) version 1.0.1 (Released March 2012) through 1.0.1f (1.0.1g, containing the fix, was released April 7, 2014).

Once a service upgrades to a fixed version of OpenSSL (or to some other cryptographic library), they will need to revoke the certificate that they had been using with with the vulnerable version of OpenSSL and obtain a new certificate. Exactly how long that takes will depend on how quickly they can get things sorted out with their certification authority. Certification authorities are going to be very busy over the next few weeks.

Only after a new, certified certificate is in place on a server that is not using a broken SSL/TLS library will it make sense for you to update your password for that service (or even trust your communication with it). Most of us simply have to wait until notified by various websites and services when and whether we should change passwords.

Certificates and keys

If you are curious about what is actually exposed by the heartbleed bug, read on. It requires some understanding of how certificates work, but I’ll try to give an overview of just the parts we need for this discussion. I will take a lot of shortcuts in the presentation and pretend that things are simpler than they actually are.

How certificates and keys work

In order for your browser and a web site to encrypt the communication between them, they need to use an encryption key. That key is typically a 128-bit number. Now, it may be that your browser and the particular website have never spoken to each other before, so they need to work out an encryption key for this session in such a way that someone listening in will not know what the key is. It’s as if they have to work out a password to share between them while communicating where anyone can listen.

The encryption key that they work out is just for that particular session. The next time your browser establishes a connection to that server, a new key is worked out. This is called a “session key”.

Establishing a session key

Your browser and the server work out a session key using something called “public key encryption”. Public key encryption is the nearest thing to magic you will find in mathematics and cryptography. When I describe what I do to school kids on career day, I say that I get to think like a criminal and do magic with math.

Anyway, the server will have a public key and a private key that are mathematically related. The public key is not a secret at all. The mathematically related private key is. It is possible to use the public key to encrypt stuff that can only be decrypted with knowledge of the private key.

So (and this is taking a big shortcut), your browser can pick a random session key and encrypt it using the server’s public key. Because only the server knows the corresponding private key, only the server can decrypt the encrypted session key. Once your browser has sent a randomly chosen session key to the server, both the server and browser can use that session key for their communication throughout that session.

The private key is a big, long number. Often thousands of bits long. And it can’t be just anything; it has to have the appropriate mathematical relationship to the public key. Clearly no human is going to be dealing with those keys directly. Typically, those keys are stored in a something that can be used by the server software and is protected by a password.

This scheme of using a password to protect a key and then have the key be used for the encryption is typical of high security software. You find this in SSH, PGP, and in 1Password. A strong key is picked by the software and that key is then encrypted with a password that a human uses. With 1Password, your data is encrypted with a random 256-bit key that is chosen when your data vault is created. Your Master Password is used (indirectly) to encrypt that key (again, I’m skimming over some details).

How heartbleed bleeds your privacy

Anyway, the heartbleed bug pretty much allows an attacker to probe a server that will end up revealing the private key. Once an attacker knows the private key, they can decrypt session keys that have been sent to the server, and thus decrypt all of the encrypted traffic that goes back and forth between the browser and the server.

Another bit of magic with public key encryption is the notion of “digital signature.” Your browser can create a mathematical challenge using the public key that only someone with knowledge of the private key can solve. This is part of how a website proves to a browser that it is what it says it is. If an attacker learns the private key of some website, then it can masquerade as that site.

All in all, the capture of a server’s private key is a bad thing, and that is what this bug enables.

Update for system administrators

Most of us ordinary folk need to wait for sites that need fixing to actually get fixed, then wait for instructions on whether we need to change passwords. But some of us need to get working. The definitive source for information about Heartbleed is heartbleed.com.  Since this article was originally written, Filippo Valsorda has published a tool for checking which sites are vulnerable (this has also finally pushed me to play with the Go programming language I’ve been hearing so much about).

Heartbleed pass

The IMAPS server passes the Heartbleed test

Valsorda has also created a web page based on his testing tool, which makes it easy for people who don’t wish to install and run the command line program to see which websites (or other services) are currently vulnerable to Heartbleed. I wanted to test the IMAP (mail access) server used by Fastmail.fm (which I use for my personal mail).  The name of the IMAP server is “mail.messagingengine.com” (which I happened to look up in my Email accounts category in 1Password). Because I wasn’t testing normal HTTPS, which used port 443, I also had to enter the port number for IMAPS, 993.  So what I put in the form was “mail.messagingengine.com:993″. This nicely passed the test at the time I tested.

Heartbleed fail example

The Heartbleed test fails for Dreamhost at the time of testing

To test a website, you do not need to put in the port number. The test will default to port 443 (HTTPS). So I was able to test Dreamhost.com by just using “dreamhost.com” in the form. At the time I tested, dreamhost had not updated to the fixed version of OpenSSL, and so the test reported it as vulnerable.

Patching OpenSSL isn’t enough

It is important to remember that during the period that your site was vulnerable attackers could have captured the key for the SSL certificate. Once they have your key, they can (under most circumstances) continue to read and manipulate traffic to and from your site. So the next step is to generate a new certificate and get that signed by a Certificate Authority. This is also a good opportunity to ensure that your RSA or DSA key is at least 2048 bits long. 1024 bit RSA and DH keys are no longer considered safe.

Once you have your new certificate signed and in place, you should inform users that their sessions may have been compromised prior to the installation of the new certificate. They should then change their passwords and take whatever other action is appropriate given that confidential data may have been exposed.

Updates

The bulk of this article was drafted late Monday (April 6) night and in the wee hours of Tuesday morning. We will have a series of other articles and announcements coming soon, so please continue to watch the Agile Blog for news here and 1Password on Twitter,  on Facebook, and on App.net. We will also be providing only minor updates to this post, as we prepare new ones.

April 12

  • A new certificate for agilebits.com was put in place on April 10 and Dropbox.com put a new certificate in place on April 11.
  • Now that Dropbox is using a new certificate, we’ve removed the earlier advisory for users of the 1PasswordAnywhere feature.
  • We’ve added some links to password changing instructions for 1Password 4 for Mac.

Your Master Password is your defense from Dropbox breaches, real and imagined

1Password in DropboxRumors of a Dropbox data breach spread this weekend, a breach that ultimately turned out to be false. But even in instances of false alarms, it is useful to remind 1Password users that their 1Password data cannot be decrypted without the Master Password. So let me take this opportunity to remind everyone that your 1Password data cannot be decrypted without your Master Password. If someone steals your 1Password data – whether from the theft of your own computer or through the breach of a sync service – they cannot decrypt it.

Fact checking

It is worth noting that when a perpetrator of a rumor like this self-identifies as “Operation Troll Security”, it might be worthwhile to double check their claims before jumping to conclusions or even reporting the claims further. This is particularly true if a perpetrator has a history of claiming responsibility for every notable site outage, then laughing at people who believed them. Operation Troll Security doesn’t often tell the truth, but it may be wise to heed one particular tweet:

https://twitter.com/1775Sec/status/421861679631044608

Despite the fact that the claims of a Dropbox breach were a complete hoax, it still is worthwhile to point out some things about the security of your 1Password data if it ever does fall into the wrong hands.

End-to-end encryption

1Password uses what is called “end-to-end” encryption. 1Password on your computer or mobile device encrypts your data with keys that are derived from your Master Password. Those keys are never stored anywhere or transmitted. Nobody, not even us at AgileBits, ever sees those keys or your Master Password. This is why it absolutely essential that you don’t forget your Master Password. We cannot reset it or reconstruct it. Your data can only be decrypted by you.

We designed 1Password this way from the outset because we knew that computers get stolen and services get compromised. By placing all encryption and decryption under your control, we become far less reliant on the security of any sync service.

Protecting Master Passwords

If an attacker does get hold of your 1Password data, the only feasible way for them to attempt Password Based Key Derivation Function diagramto decrypt it would be to try to guess your Master Password. Of course, they wouldn’t sit there typing in guesses. Instead they would run automated password guessing systems against the data.

We have a long history of building mechanisms into 1Password’s data format that make it harder for attackers to guess your Master Password. When we released 1Password 2.5 in 2007 with the then new Agile Keychain data format, we added PBKDF2 so that anyone trying to run automated password guessing systems against captured 1Password data would have to perform lots of slow computation for each guess. You can read more about PBKDF2 and this aspect of our design in an older article of mine, Defending against crackers: Peanut Butter Keeps Dogs Friendly, Too. Many of the details have changed over the intervening years, but the essential concept remains the same.

Toward better Master Passwords

DicePBKDF2 makes it harder for those automating password guessing, but it does have limits. You need to do your part by choosing a good Master Password. Even a small improvement to a Master Password goes a long way. Adding a single truly randomly chosen digit to the end of your Master Password makes the attacker work ten times longer to guess it. Adding a truly randomly chosen word make the attacker work thousands of times longer. Adding two truly randomly chosen words makes the attacker work tens of millions of times longer.

You will note that I emphasized the phrase “truly randomly” a few times there. That part is crucial. People turn out to be very unrandom even (especially?) when they are trying to be random. If you follow our advice in Toward Better Master Passwords, you will see how you can securely pick words at random to add to a Master Password. Hint: It involves rolling dice. It’s fun!

A hoax is a hoax, of course of course

Even though the report of a Dropbox breach was a hoax, you still may ask what role Dropbox security plays in the security of  your 1Password data. I hope that this article helps explain that and how using 1Password can keep your secrets safe. I look forward to further discussion in our forums.

The NSA can do what to my iPhone?

30c3After Der Spiegel, along with Jakob Appelbaum at the 30th meeting of the Chaos Computer Club, published an astonishing trove of documents revealing a great deal of the extent of their penetration of the network and capabilities to install spying mechanisms into individuals’ computers and devices, one of the least significant documents is getting the most press attention. That document, is of course, the one describing the DROPOUTJEEP program.

If you were to believe press reports, you would believe that every iPhone on Earth could be (or is) infected (“implanted” in NSA jargon) with NSA spyware. But what happens if we actually look at the document?

S3222_DROPOUTJEEP

Overlooked facts about DROPOUTJEEP

  1. The document is from 2008 describing 2007 technology. Thus it only applies to the first iPhones.
  2. The “implant” can not be done remotely. It requires “close access” which probably means physical access to the phone.
  3. It had not been deployed at the time the document was drafted.

For a fuller discussion of what the documents do and don’t say, I refer you to an excellent article by Graham Cluley, “DROPOUTJEEP. Can the NSA spy on every iPhone on the planet?“. Indeed, Cluley wrote the article that I would have liked to write; so I will just highlight a few points instead of repeating things.

Where do things stand now?

Question: What can we conclude about the NSAs current capabilities and attacks against recent iOS devices (iPhones, iPads, iPod Touches)?

Answer: Almost nothing.

iDevice security has improved enormously since the first iPhones. The difference between the iPhone 3G and the iPhone 3GS alone was a huge leap. (Not a minuscule “quantum leap”.) Though of course there have been several publicly disclosed or discovered vulnerabilities in various versions of iOS over the intervening years. So while we know about improvements in iOS security, we don’t have any information about how successfully the NSA has been at keeping up (or staying ahead) of that. The only thing we can safely assume is that they would like to have the capabilities (incorrectly) described in the media and that they will have had highly skilled people working on it.

Would NSA spyware be able to break or work around 1Password security?

We have no idea of whether the NSA can break or go around 1Password security. The tool described in DROPOUTJEEP would have been able to ship your encrypted 1Password data to the NSA. That is, it could “remotely pull/push files from the device”, which would include any files—documents, photos, and that sweet GarageBand track you’re tinkering with. But there is no indication from the listed capabilities that it could grab your Master Password, keys, or encrypted data. Still, the “safer” assumption is that they could have.

As for today, we again have no idea. The question of how well any security product stands up against threats from a compromised operating system is tricky. In a technical sense, once the operating system is compromised then nothing running on it can be trusted. But in a practical sense, applications can sometimes put up meaningful defenses against some of the attacks that do exist from a compromised operating system.

Nobody can realistically claim that they are safe from the NSA. We simply don’t know their full capabilities. But 1Password does provide end-to-end encryption, with no reason to believe that the encryption we use can be broken by the NSA. So we can say that 1Password is “PRISM Resistant“. When the NSA captures your encrypted 1Password data, they – in all likelihood – need to guess your Master Password to decrypt your data. If they already control the computer or device you are using, then they can probably get around 1Password’s security.

The ends of end-to-end

[Update: This section was added on January 1 2014 to more explicitly spell out the implications of the previous paragraphs.]

1Password provides end-to-end encryption. This is what makes it “PRISM Resistant”.  If your data is captured by any attacker, governmental or otherwise, from your machine or from a sync service, we believe that the best attack is to try to guess your Master Password. PRISM represents a threat that end-to-end encryption does defend against.

End-to-end encryption does not cover the situation where the attacker has compromised the system on which you are decrypting your data. That is, if the attacker controls something that you use at either “end” of your end-to-end encryption (such as the operating system), then this poses a threat that end-to-end encryption does not solve.  Thus DROPOUTJEEP represents the kind of threat that end-to-end encryption does not defend against.

DROPOUTJEEP doesn’t tell us about NSA current capabilities, but it does tell us that the NSA in the past has had the capability and intention to compromise iPhones.  It is more than plausible that they have continued to develop the program over the past six years. To the extent that they have been successful (something we simply don’t know), then we can only advise people to behave as if nothing on their devices is protected from the NSA.

Although it should go without saying, I will repeat myself:  If the US government is aware of vulnerabilities in iOS (or any other system) and has failed to disclose those vulnerabilities to Apple, we have absolutely no choice but to consider the US government to be “black hats”.

Miscellany

I started out saying that I think that DROPOUTJEEP is one of the least significant of the documents released. I haven’t studied more than just a few, but I find the overall penetration of the Internet the most disturbing at this point.

AgileBits is a Canadian company comprised of people from a variety of different countries. But I am a US Citizen, and as one I am furious that my own government is working to make my job harder. My job is to help you keep your data secure. Every time my government discovers (or even creates) a vulnerability in network and application security that they don’t disclose to the vendor is a time when they are harming everyone’s security.

Their activity also makes it extremely difficult for people to know who they can trust. I will state again that we have never been asked, pressured, or ordered to do anything that would weaken our products or your security, nor have we ever deliberately weakened our products. For a discussion of what reasons you might have to believe us when we say that, see 1Password and the Crypto Wars.

Update: Apple statement

Apple appears to have issues a statement saying that it had no knowledge of any back door into iOS. The statement, as reported by All Things D reads:

Apple has never worked with the NSA to create a backdoor in any of our products, including iPhone. Additionally, we have been unaware of this alleged NSA program targeting our products. We care deeply about our customers’ privacy and security. Our team is continuously working to make our products even more secure, and we make it easy for customers to keep their software up to date with the latest advancements. Whenever we hear about attempts to undermine Apple’s industry-leading security, we thoroughly investigate and take appropriate steps to protect our customers. We will continue to use our resources to stay ahead of malicious hackers and defend our customers from security attacks, regardless of who’s behind them.

[Update: This post has been edited to correct the Spelling of Appelbaum's name and to explicitly mentioned that there have been several vulnerabilities in more recent versions of iOS over the intervening yeas. It has also been updated to include a section that explicitly spells what end-to-end encryption does and doesn't protect you against.]