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

Time to give 1Password 4 for Mac’s Security Audit a whirl

1Password Security AuditIt was bound to happen eventually. A massive Adobe data theft of 130 million customer names, emails, encrypted passwords, source code, and more will enable almost limitless password reuse attacks in the coming weeks.

Suppose you are one of the 130 million people who’s oddly encrypted passwords were among the Adobe password breach. Suppose that you used the same password there as you do for PayPal.

To make matters worse, suppose you actually listed that fact in Adobe’s password hint. Since the malicious attackers dumped the Adobe data online, a quick check of Adobe customer password hints shows that there are more than 700 that say things like “paypal” or “sameaspaypal”. There are more than 20,000 hints referring to “bank”. I will talk about password hints at some other time; my point here is all about password reuse.

Only a fraction of the people who are reusing passwords will make that clear in their password hints. We already know password reuse is common. We also know that criminals do indeed exploit password to steal from people.

I am very tempted to explain all about Adobe’s peculiar method of storing passwords. It’s really a cool story with lots of interesting lessons, and explaining it would involve poorly encrypted pictures of a penguin.

I am also tempted to dive into gory details of the statistical properties of the data, the analysis of which has kept my computer busy for days on end. Likewise, I could rant about Cupid Media’s failure to encrypt or hash passwords for 42 million customers. Or I could talk about privilege escalation and the MacRumors discussion forums breach of 860,000 hashed passwords a week earlier, leading to the capture of all 860,000 hashed passwords.

But it is far more important for me to repeat what we’ve said in many different ways and at many different times: Password reuse—using the same password for different sites and services—is probably the biggest security problem with password behavior.

We want to fix that.

Knowing the right thing to do is easier than doing the right thing

Like most people, you weren’t born using 1Password, it’s something that came to use later in life. Now that you use 1Password, you will (or should) be using the Strong Password Generator when you register for a new website so you get a strong, unique password.

But think back to those dark days when you needed to come up with passwords on your own. You probably picked from a small handful that you had memorized, so now you’re stuck with a bunch of sites and services for which you used the same password.

Security Audit selections

Getting all of those old passwords sorted out is going to be a chore, but it doesn’t have to be done all at once. Best of all, 1Password 4 for Mac can help, thanks to its new Security Audit feature.

Let’s use an analogy: say that Molly (one of my dogs, and not really the cleverest of beasts) has just started using 1Password. She has a few passwords, but not many. Even though she doesn’t know how to push open a door that is already ajar, she can make use of the new Security Audit tool in 1Password for Mac.

In the left sidebar of 1Password 4 for Mac, down toward the bottom, there is a section called “Security Audit”. When Molly clicks (or paws) “Show” next to “Security Audit” she sees a number of audits available. She can select “Weak Passwords”, which will show her all of her items with weak passwords. She can also look at password items that are old. But the selection we are interested in today is “Duplicate Passwords”.

Security Audit: Molly's duplicates

Security Audit in 1Password 4 for Mac, displaying Molly’s duplicate passwords

What Molly sees is that she has two sets of duplicates. One of them is used for two Logins, and the other one is used for four Logins. As we can see, her Adobe.com password of “squirrel” is used for her Barkbook, Treats R Us, Cat Chasers Logins as well.

Molly transfixed by "squirrel"Molly should, of course, go to each of those sites and change her passwords on them. But there are squirrels in the back yard to bark at, and changing all of those passwords may seem overwhelming. So Patty (the cleverer dog in the family) advises Molly to think about which of those Logins are most crucial. Molly can’t tolerate the thought of anyone else getting a treat; so she starts with Treats are Us.

This does mean going to the Treats are Us site and using its password change mechanism. 1Password is smart, but it isn’t quite smart enough to go browsing through the sites to find their password change pages. Molly may decide that her Barkbook Login is also very important, and so will change that one right away as well.

Ideally, Molly should fix all of her weak and duplicate passwords as soon as possible. And as Molly has only a handful of Logins, she could do that. But for those of us who may have a large number of old accounts, it is probably best to check Security Audit and update reused or weak passwords at the most important sites first. Then, updating other passwords a few at a time is an easy way to make all our accounts much more secure.

1Password and The Crypto Wars

Of all of the revelations about the NSA that began in June and continue to this day, the one that has shocked me the most is the fact that the United States National Security Agency has been deliberately inserting weaknesses into security products and even into NIST standards. In light of this, it is fit and proper for anyone who relies on 1Password for their security and privacy to ask whether 1Password has been, or could be, tampered with to deliberately weaken it.

The easy questions

Has 1Password been deliberately weakened?

No.

Have we, AgileBits, ever been asked/compelled/pressured/contacted by any entity asking us to weaken 1Password?

No.

Could we be compelled to weaken 1Password or allow for the weakening of 1Password?

Not without substantial risk that such attempt would become public.

Those questions are the easy ones to answer. The harder question is why you should believe those answers.

Why should you believe us

It is impossible to absolutely prove that our answers to the easy questions above are truthful. But what I can do is provide a number of more verifiable claims, each of which makes it harder for us to lie about any of this. In combination, these should be enough to persuade you that there is no backdoor (deliberate weakness) in 1Password and that it would be very unlikely for one to be introduced.

They can’t gag all of us

We have developers in four separate countries: Canada (AgileBits is a Canadian company), the United States, the United Kingdom, and the Netherlands. The gag orders that accompany National Security Letters in the US would not bind non-US citizens outside of the US. Likewise the Canadian, British, or Dutch analogues to National Security Letters wouldn’t bind US citizens. To compel all of us to betray our customers and principles, they would need to coordinate that legal compulsion in four jurisdictions.

This doesn’t entirely rule out the possibility of such a set of gag orders, but it does make such compelled silence much harder to achieve. This also doesn’t rule out other avenues of attack. In particular, could just one or two people within AgileBits sneak in a backdoor? We’ll talk about that below, but note that the inability to gag so many of us means that a backdoor would have to remain unknown to most of us.

Our lack of data collection is verifiable

Your 1Password data is under your control. Out of the box, 1Password creates a local data file (your “vault”) and sync is disabled. We never have the opportunity to see your Master Password or even your encrypted 1Password data. 1Password not only gives you “end-to-end” encryption, but our overall design means that we are never in a position to turn over or intercept your data. We simply never see it in any form whatsoever.

Furthermore, we never see how you use 1Password. We don’t know what sites you log into, we don’t know how many 1Password items you have. Indeed, we don’t even know whether you use 1Password or not. We offer a soon-to-be-incremented number of data synchronization methods, none of which involve us ever having the opportunity to intercept your data. When 1Password 4 for Mac arrives soon, Wi-Fi sync (currently in testing) will allow you to sync locally, meaning your data never has to leave your local network.

You can monitor 1Password network activity for yourself to confirm that your data, even encrypted, is never sent to us. All of this dramatically reduces where a backdoor could be inserted.  Indeed, it eliminates the otherwise easiest to insert and most difficult to detect backdoors. So an entire range of attacks is already off the table.

As always, this doesn’t rule out all kinds of mischief, but it substantially limits the scope and opportunity for an attack.

Our data format is verifiable

We have been very open about providing the details of the encryption and data format that 1Password uses. Anyone can verify that 1Password does produce the files we say it does. They can also examine whether that over all design is strong.

This doesn’t rule out every kind of sabotage that could be done, but it does rule out a broad range of some of the easiest lines of attack. Because this limits where a weakness could be introduced, it’s harder for a deliberate weakness to be introduced that isn’t noticed by others who can access the source code.

As a consequence of this, everyone with access to the source code knows where to look for possible tampering. This makes it harder for a backdoor to be introduced without it being noticed by many of us. As pointed out above, they can’t gag us all.

Lavabit has set a precedent

One company, Lavabit, has shut itself down rather than comply with betraying their customers. This increases the risk of discovery to those trying to compel developers to introduce weaknesses.

It is impossible to predict how we would react in absence of having the full details of such compulsion in front of us; there are just too many unknowns and too many forms of compulsion. But the very real possibility that we would shut ourselves down (which would be public) rather than sabotage what we do and love should act as some deterrent to those who might wish to compel us to introduce a backdoor.

Only communications tools appear to be targeted

From the most recent revelations, the targets appear to be communication tools and protocols. 1Password is not such a tool. This doesn’t mean that the NSA couldn’t change their focus, but from what we know so far, 1Password is not the kind of thing they are after.

Going around crypto instead of through it

Even if you don’t find any of the individual reasons listed above to be persuasive, they interact powerfully. In combination, they make it much harder to get a weakness into 1Password without taking on large risks of getting caught and failing. Any attacker, including the NSA, will avoid high risk, high cost attacks if there are safer and easier alternatives. I’m therefore confident that the NSA would rather go around 1Password than through it.

Crypto Wars II

In the 1990s, there was a series of debates, pressure, civil disobedience, and cryptographic developments that have come to be known as “The Crypto Wars”. At the heart of this was the US and other governments’ efforts to prevent people from having access to cryptographic tools which those governments couldn’t break. In the end, governments (seemingly) surrendered, in large part because the tools they wished to use to enforce those restrictions (export restrictions, the Clipper Chip) just weren’t going to work.

What the 5 September, 2013 revelations show is that the US government has taken a different tack. The Crypto Wars may never have ended. Instead of explicitly and openly trying to limit the power of the cryptographic tools allowed to the public, they are now surreptitiously sabotaging the tools that we all use. As before, this will be fought on the political front—people telling their representatives that they don’t want hobbled security tools—and on the technological front—building better, stronger, more robust and verifiable systems.

Our role in this as a company is to be transparent about our approach to security while keeping your 1Password data protected.

How long should my passwords be?

1P4 icon“How long should my passwords be?”

A question like this depends on what kinds of password we’re talking about. The requirements for your 1Password Master Password, which you need to be able to remember and type, are very different from passwords you generate using the Strong Password Generator, which you never even have to look at.

The advice here isn’t changed at all by the recent news that the GPU-optimized version of hashcat, a password cracking tool, is no longer limited to attacking 15 character passwords. There seems to be some confusion about what that news means, which I’ll address further below.

Passwords from the Strong Password Generator

Wells Fargo: Your password must be 6 to 14 characters

Let’s start with the passwords created by 1Password’s Strong Password Generator.  Obviously, your password can’t be longer than the maximum length enforced by the website, but let’s leave that aside. Let’s suppose that the site or service you are generating a password for does better than my bank. There are lots of nifty options that you can set in our Strong Password Generator, but in order to keep my examples simple and stick to the most conservative assumptions, I’ll just use examples where we set the Strong Password Generator to create mixed case letters only.

Strong Password GeneratorLet’s take a look at a specific example I’ve set. I’ve set the Strong Password Generator to create a password that is 23 characters long, no digits, no symbols and characters are allowed to repeat.

Oops, did I just show what the Strong Password Generator might look like in the 1Password 4 menubar mini app? Wait, did I also just reveal  there might be a menubar mini app coming in 1Password 4 for Mac? And how did my keyboard get so… porous?

Moving on, the first character can be any one of a the letters “a” through “z” or uppercase “A” through “Z”. That is 52 different possibilities for the first of the 23 positions in this password. The second character can also be any one of those 52 letters. If we limited this password to just being two characters long, that would mean we could have 52 × 52 possible passwords; that’s 2704 possible passwords. A password cracker like hashcat or John the Ripper could rip through all of those in an instant.

At three characters long, we have 52 × 52 × 52 possibilities. That’s 140,608 possibilities, but still a joke of a password. When we get up to about 10 characters long we have 52¹⁰ possibilities, otherwise known as a 17-digit number. That will make high-end, specialized password cracking systems really sweat. Now let’s take a look at my 23 character password, as it has 52²³ possibilities. That number is approximately 2¹³¹, which is bigger than 2¹²⁸. As it happens, I wrote about just how hard it is to guess one of 2¹²⁸ possibilities a while back.

Put simply, if the world’s fasted computer could check a password as quickly as it can add two numbers, and if you had a billion of those computers all guessing passwords, it would take more than a million times the age of the universe to go through all of the 52²³ possibilities from a 23 character password created with 1Password’s Strong Password Generator. Put even more simply: nothing is going to crack a password generated with our Strong Password Generator this way.

Length of a Master Password

Your Master Password should be no longer than you can (teach yourself to) comfortably type. It also needs to be something you can remember. As a consequence, it will never be as strong as a 23 character password generated by 1Password’s Strong Password Generator. Because of this shortcoming of the human brain, we’ve taken taken steps to slow down the cracking rate that tools like hashcat and John the Ripper can achieve against a 1Password data file.

XKCD "I'm so random"

You can make a strong, memorable, and managable Master Password by using a truly random process to select words. Thinking them up yourself is emphatically not random.
So the system I describe in Toward Better Master Passwords involves rolling dice against short words from a list. Please see that article for the description. You can also read about how well these sorts of passwords withstand John the Ripper and hashcat. Note that the recent news about hashcat password limits doesn’t change our previous advice about password length, which is why I’m just referring you to those.

55 Character passwords, oh my!

HashcatSome readers may have heard that ocl-hashcat-plus, a spectacularly fast password cracking tool, is no longer limited to cracking 15 character passwords. It can now handle passwords up to 55 characters. This is a massive change to how hashcat operates. I’m sure it pains Jens Stuebe (AKA atom), hashcat’s developer, to surrender some of the brilliant optimizations that came with the 15 character limit, but as more people start to use passphrases, this was a change he had to make.

It is important to realize what this news does and doesn’t mean. Users of hashcat are now free to try to crack longer passwords. They no longer have to switch to some other tool like, say, John the Ripper or a different edition of hashcat, for going after long passwords. It still takes as much time today for hashcat to try a candidate password as it did last week. Actually, the changes that Jens had to make actually slow hashcat down by about 15%, but that really isn’t significant in determining what sorts of passwords are within reach.

Some people appear to have misunderstood the news. They may have mistakenly thought that the work previously needed to crack a 15 character password will now be able to crack a 55 character password. But that isn’t the case at all. A 25 character password is as strong today as it was before the announcement.

If, however, you use a passphrase that can be found in a book or on Wikipedia, you should change it. As more people – focusing only on password length – start to use such passwords, attackers start crafting their tools to attack them, as you can see from Josh Dustin‘s and Kevin Young‘s presentation at PasswordsCon.

But, of course, actual phrases in a natural language are anything but random.

Password advice should look ahead of the technology

Back in April when I discussed 1Password Master Passwords in light of hashcat’s speed, I studiously did not mention the fact (which I was well aware of) that hashcat was restricted to 15 character or less passwords. I could have said, “just make sure your password is longer than 15 characters and you will be safe from hashcat.” But I did not say that.

John the Ripper

I considered the 15 character restriction in hashcat as a technical, idiosyncratic design choice of one particular tool. It could change any day (as it has) and other tools could exist without that restriction (they do, including both other editions of hashcat and John the Ripper). When devising advice, we need to not limit ourselves to the idiosyncrasies of one particular tool. We need to look at the big picture—not just at what the tools do today, but at would they easily could do tomorrow.

There will still be times when advances in password cracking require an adjustment in what we do. For example, we’ve raised the number of PBKDF2 iterations used in 1Password over the years, and the data format used in 1Password 4 offers even tougher resistance to crackers. But on the whole, we design for the future. As a result, it shouldn’t be surprising when our reaction to some news or other is, “it doesn’t impact 1Password or how people should use it.”

On the NSA, PRISM, and what it means for your 1Password data

PRISM: 'really freaky'.It should come as no surprise that the NSA (United States National Security Agency) has easy access to data that ordinary people store online. Section 215 of the PATRIOT Act (of 2001) and section 702 of FISA (renewed and extended many times over its long history) give the US government the legal authority to gather such data and to keep the fact of gathering that data secret.

What is new is that there are confirmations of the prior suspicions that they are gathering telephony metadata about everyone, even if there is no specific reason to connect those people to a specific investigation, and that they have mechanisms in place to make it quick and easy to obtain data stored with various Internet service providers.

If the US government wants your data stored with Apple or Dropbox, it is easy for them to obtain it with no notification to you that they are doing so. This fact is not news. The laws have long enabled them to do that.

The news is (a) that the NSA and FBI have been collecting data about telephone calls on a large and indiscriminate scale while publicly stating that they weren’t, and (b) that they have mechanisms in place with various service providers, including Apple, to be able to collect data from individuals. The latter, we are now being told, is not indiscriminate; and the actual mechanisms are unclear.

Does this matter for 1Password users?

I think this matters for everyone, but here I will focus only on what this specifically means for 1Password. The latest news really changes little. We have gone from a situation where the government could “easily obtain the data” to one where “it’s so easy that they may have already made a copy.” Looking only at implications for 1Password, this is not anything new. The US government can easily obtain data you may store on iCloud and Dropbox. That just isn’t anything new, and so it isn’t anything new for 1Password.

Nonetheless, this does give us an opportunity to talk both about what data we at AgileBits may have about you and also with how resistant your 1Password data might be to the NSA.

We don’t know who you are, but we love you

We’ve never been asked to turn over data about you. Sure, some of that is because we are a Canadian company, but most importantly is the simple fact that we really don’t have any data to turn over. The easiest way for us to protect your data and data about you is to not have that data in the first place. We can’t reveal or abuse data that we don’t have. You can read the details of the data we do and don’t have.

In summary, we only have information about you that you explicitly provide to us. If you sign up for our Newsletter, we will have your email address. If you purchase from our store directly, then we have the information you provided at time of purchase (though we only retain partial credit card details). If you contact use through support, we have a record of those communications. If you make your purchase of 1Password through Apple’s app stores, we are only given aggregate information (how many people from which countries).

We do not have your 1Password data. We do not know your 1Password Master Password, We don’t even know if you use 1Password. We do not know how many items you have in your data or their type. Our image server (used for Rich Icons in 1Password 4) is set up in a way that we never see the IP addresses of individual requests. That server never gives us information about what is in any individual’s 1Password data.

Quite simply, you don’t have to be concerned about AgileBits gathering information about you. We just don’t have much information in the first place.

How NSA-proof is your 1Password data?

Returning to the (unsurprising) fact that the US government can easily obtain your data from cloud services, we can ask about how resistant the 1Password data formats might be to an attack by the NSA.

As we’ve often said, we designed the data format used in 1Password with the knowledge that some people would have their data stolen. It might get stolen because their computer is stolen or it might get stolen because of a data breach at a service like Dropbox. Either way, we’ve assumed that there would be circumstances where an attacker may get hold of your 1Password data, and so we designed the data formats with encryption to keep your secrets secret.

We can only guess (but make reasonable guesses) about the NSA’s capabilities. We can’t rule out that there might be some flaw in the design of our data format that neither we, nor anyone whose studied it, have found but that the NSA is aware of and able to exploit. Finally, there is the potential use the NSA could make from your 1Password data even without decrypting it.

In judging NSA capabilities, we need to keep in mind that they have a history of discouraging the US government from using systems that the NSA could break. If the NSA could break AES-CBC-128, then they would not be advising US government agencies to use it. Interestingly there is a history of the US and UK governments advising foreign governments to use cryptographic systems derived from Enigma, which the US and UK could break at the time.  But the NSA has (correctly) operated under the assumption that if they have found a way to break something, others will too.

Tweet from @EdwardTufte: PRISM "providers": classic PPT statistical graphic: 13 logos, 10 numbers, 9 bubbles, 1 giant green arrow. #powerpoint

It’s also reasonable to assume that the gap between the kinds of cryptanalytic techniques that the NSA has, and what the academic community has, is not as large as it was in the past. We did see evidence of the NSA (presumably) using a novel technique in Flame. We know that they are ahead, but as the number of people who publicly study cryptanalysis increases, the gap should narrow significantly. It certainly appears that their skills in designing presentation slides are more than a decade behind readily available and documented public techniques.

From these I comfortably operate on the assumption that the actual building blocks (AES, etc) and the constructions (CBC) we use are not broken.

Of course, one area where the NSA has clear, unmatched power is with computing resources. Our estimations of how long it would take a password cracker to guess a Master Password have been based on the kinds of tools that the public password cracking community has available.

A Master Password with the equivalent of 60 bits of entropy is going to be out of the reach of even the most dedicated civilian password cracker, but may be within reach of the NSA.

Cray XMP

There may be non-cryptographic flaws in cryptographic software, including 1Password, that the NSA is able to exploit, and that nobody else knows of. That is, they may know a way to break 1Password’s security without having to break the crypto. Naturally, we work  hard to keep 1Password free of such vulnerabilities, but that is no guarantee that there aren’t some which the NSA is aware of and that we are not.

Finally, if they are collecting massive amounts of data, they may be able to make use of the non-encrypted data within our data formats. Our newest format reduces that particular threat, but it is still possible to see when items were created and modified along with how many items a person has in their 1Password data. Also, item categories (whether something is a Secure Note or a Login or a Credit Card) is not encrypted. As discussed in many places, the Agile Keychain format, which we developed in 2007 and began phasing out with 1Password 4 for iOS in December, leaves Title and Location unencrypted, so it’s similar to a browser bookmark file. However, in the case of an investigation by the NSA, that probably tells them little that they already didn’t have access to.

The right tool for the right task

Security failures often happen when people don’t use the appropriate tool for the task they are trying to achieve. 1Password is extremely good at what it does. It keeps the secrets (passwords in particular) you store within it safe, and makes it easy for you to use those secrets when you need them. This is an extremely important part of your security, and we are very pleased to provide that.

If, however, your goal is to keep your online activity secret from the government, then 1Password can only be a tiny part of what you need to do. As an analogy (and all security analogies ultimately fail; so don’t take this too far), consider a system, say 1Passlock, as providing a very good lock on your house making it impossible for someone to break into it. 1Passlock, however, would do little to prevent someone from learning the location of your house, so you would also need to find something in addition to 1Passlock to conceal your house’s location.

The point of this terrible analogy is that you need to find the right tools for your particular security goals and try to make sure that those tools work together.

Avoiding the cloud

1Password in DropboxOur approach has been to plan and design for the case where your data can be captured from anywhere, whether it is stored on services like iCloud or Dropbox, or not. However, we have learned that a notable number of people don’t agree with storing their data in the cloud at all. There are 1Password users who reject the idea of storing their 1Password data on any system outside of their control no matter how strongly their 1Password data is encrypted.

iCloudWe would like you to have as much control over your own data as possible. This way, it doesn’t matter whether you agree with me about the relative risks of capture from local computers. It should be your choice to make. We have provided a (beta, Mac only) USB Syncher, but we are also exploring other approaches that may work out as better solutions for synchronizing your 1Password data without having to rely on services outside of your control. At this point, I can tell you nothing about the kinds of approaches we are exploring, and I do not yet have a timeline to share.

In conclusion

The latest news does not substantially change the security situation for 1Password. It does, however, focus more attention on the relative safety of your 1Password data when using Dropbox or iCloud to store and synchronize said data.

We anticipate that there will be some creative discussion of this, and so have already created a specific place for this in our forums.