1Password security doesn’t depend on SSL
by Jeffrey Goldberg on
The security of your 1Password data does not depend on the security of SSL/TLS. 1Password keeps your data encrypted with your Master Password. This means that, even if an attacker is able to intercept the communication between your system and a sync server, they will not be able to decrypt your 1Password data.
From the beginning, 1Password has been designed with the expectation that some people would have their 1Password data captured. As unfortunate as it is, these things happen, whether it could get stolen from synchronization servers, from people’s own devices and computers, or during transit. Because 1Password provides end-to-end encryption, it does not rely heavily on the security of the communication channel used for storing and synchronizing 1Password data.
This is good news, because the bad news is that there is a serious bug in Apple’s implementation of the SSL/TLS in some versions of iOS and OS X. If you haven’t already done so, update your iPhones, iPads, and iPod Touches to at least iOS 7.0.6 (or iOS 6.1.6 if you are still using iOS 6) by launching the Settings app and going to General > Software Update.
Do this as soon as you can. Put this blog post on hold and do it right now, if you can (then come back and finish, because this is important). Keep an eye out for an OS X update, too, as we all hope it’s coming soon.
SSL/TLS is the protocol used to secure most internet connections. It puts the “s” in “https“. The bug means that attackers who have sufficient control of a portion of a network you are using can break some of the “secure” connections between your device and some server. That is, some of these “secure” connections are not as secure as we would hope.
The actual details of the bug are very interesting and suggest a number of important lessons, but I will have to leave that for a separate article. Instead, let’s talk about what this means (or doesn’t) for 1Password.
The SSL bug does not affect 1Password’s protection of your data in any way since 1Password does its own encryption of your data. This means that wherever your data resides, it is protected by strong encryption and your Master Password. So please do make sure that you have a strong, unique, memorable, and easy to type Master Password; that is your best protection.
While Apple’s SSL bug doesn’t affect 1Password directly, it does open up a way for an attacker to learn some of your passwords if you use them over a compromised connection. When you use Safari and other clients (though not Chrome or Firefox), a supposedly secure connection between your browser and the the web server could be intercepted. This means that when you submit a password on a web page, whether or not the password is handled by 1Password, it can be intercept en route to the web server.
This not only applies to Safari, but also Mail and other software running on Macs that make use of Apple’s SecureTransport tools. 1Browser, the 1Password web browser built into 1Password for iOS, would also have been subject to this along with Mobile Safari and many other apps and tools on iOS.
But of course, you have all performed the software update on your iOS devices by now, right?
We have no reason to believe that this vulnerability has been actively exploited, but now that it is known it is important to get a fix out for OS X quickly. Until that is done, I am taking a little break from my beloved Safari and switching to another browser on the Mac. Fortunately, 1Password supports Firefox, Chrome, and Opera in addition to Safari, so I can make this switch with ease. Unfortunately, that switch does nothing for Mail.app and other utilities that rely on OS X’s SSL implementation.
To exploit Apple’s SSL bug, an attacker needs to be in a “network privileged” situation. They need to control a portion of the network between you and the service you are trying to talk to. Any Internet Service Provider or telecoms operator is obviously in a position to do so, as are governments that can compel those operators to participate. So are the operators of local networks such as in coffee shops, hotels, work places. If they (or anyone who breaks into such systems) will also be in a “network privileged” situation.
As I now say for the third time (and what I tell you three times is true), the security of your 1Password data does not depend on SSL. 1Password does its own encryption, so even if your SSL connection is compromised, no one will be able to decrypt your 1Password data without your Master Password.
There are a couple of places where 1Password does use SSL/TLS, but these do not effect the security of your 1Password data.
When you update 1Password or download it from us, that connection uses SSL. In this case, the goal isn’t to keep the download secret but to ensure that you are fetching 1Password from a bona fide source. Apple’s SSL bug could enable an attacker to subvert that check and the authenticity of your download. That check, however, is only one of several checks and safety measures to ensure that your copy of 1Password is the real deal. It is neither the last nor the most important defenses against “evilgrade” updates.
Both our updater and your operating system check the digital signature of the application before installing or running it. The details differ between 1Password for Mac and 1Password for Windows. On the Mac there is a check performed by the 1Password updater, and there is also a check performed by Gatekeeper. A failure of SSL to do its job only means that some potential attacks make it through the first of multiple defenses.
If you have enabled Rich Icons in 1Password 4, then the fetching of site and application icons takes place over SSL. An attacker who has been able to exploit the SSL bug would be able to monitor that traffic. However, such an attacker is already able to read your SSL web traffic and would have little need to know what rich icons 1Password is fetching, as they already know what websites you visit by watching you visit them.
Apple’s SSL/TLS bug is a big blunder. Hopefully it has not, and is not, being exploited. It also tells a number of stories: some about how errors can sit in plain sight without being noticed, others about how backwards compatibility enable downgrade attacks, and others the importance of systematically testing software. But those are stories that will have to be discussed elsewhere, so please join us in our discussion forum.