Staying ahead with security
by Jeffrey Goldberg on
We just released 1Password 3.8.11, and this seemingly minor update packs some important security changes under the hood. I’d love to share those with you all.
For a quick review, recall that keeping 1Password secure is a process, and one which requires we at AgileBits keep our eyes on the horizon for potential threats to your security. We want 1Password to be as secure in the future as it has been up to now, so read on about some of the key changes we’re making.
Also remember that 1Password 3.8.11 for Mac from our website and 3.9.2 from the Mac App Store are both our latest versions for the Mac. Their version numbers are different for now mostly to help us keep them straight.
PBKDF2 is a trick we use with 1Password to make it much harder for automated password guessing systems to crack your password if they get hold of your encrypted 1Password data file. Without PBKDF2, automated password guessing systems could guess hundreds of thousands, even millions, of passwords per second. PBKDF2 slows down the processing of your Master Password. There is no way to check a possible password without going through many cycles, called “iterations.”
This means that if you have a good master password along with our use of PBKDF2, your encrypted data is safe even if the bad guys get hold of your data file. If you want to learn more about PBKDF2, check out our previous overview on the topic: Defending Against Crackers: Peanut Butter Keeps Dogs Friendly, Too.
We were ahead of the game when we used PBKDF2 in the design of the current 1Password data file format more than three years ago. But we aren’t going to rest on our laurels. We have been phasing in an increase in the number of PBKDF2 iterations used from 1000 to 10000 or even more. Going from 1000 to 10000 iterations means that a cracker has to do ten times as much work to try a particular guess.
1Password 3.9, the Mac App Store version, can make use of a cool Lion-only feature that automatically calculates the optimal number of PBKDF2 iterations for use on your computer. When you first create a 1Password data file using 1Password 3.9, it will call the CCCalibratePBKDF function that is part of Apple’s new CommonCrypto framework. This will calculate how many PBKDF2 iterations are needed to force, say, a 500 millisecond delay on your machine. We then use this when creating the new data file. We do put an upper limit on these, because the files you create on your super powerful Mac Pro will still need to be used on other potentially less powerful devices that you sync your 1Password data file with.
1Password 3.8 needs to run on Snow Leopard as well as on Lion, so it doesn’t use the same mechanism as the MAS version. But in 1Password 3.8.11 we have set things so that a newly created data file will now use 10000 iterations instead of 1000.
These new settings apply only to newly created 1Password data files. You will have to be patient before we can provide a rock solid way of upgrading an existing data file. We need to make absolutely sure that no matter what may go wrong during a data file upgrade, you will not lose any data, and that testing simply takes time.
We have been anticipating this increase in PBKDF2 iterations for a while. One thing that we need to make sure of is that every version of 1Password you may sync your data with will be able to cope with increased iterations. Otherwise, a 1Password data file created with, say, 1Password 3.9 couldn’t be unlocked on other systems, but we’ve had the infrastructure for this change in place for more than a year.
This means that new 1Password data files will also work with current versions of 1Password on iOS, Windows, and Android. It also means that those using 1Password 3.6 on Leopard or Snow Leopard will have no problem unlocking data files created using our latest version. Users of 1Password version 2 (are there any still out there?) will still be able to work with 1Password data files that have already been created, but will encounter problems using a data file that was created with the very latest systems.
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. Existing bookmarklets, already in the browser, will continue to work if users decide to keep them. But from this point onward, you will not be able to create new ones.
The story is similar for 1Password’s Encrypted HTML export feature. The passwords for those HTML files are also not protected by the PBKDF2 technique. But the good news is that our much-loved 1PasswordAnywhere feature will continue to work. 1PasswordAnywhere actually uses the same data file as the 1Password application itself, so there are no worries about its data format.
The Login Bookmarklet and Encrypted HTML export features were meant as temporary measures until something better could be put in place. 1PasswordAnywhere, 1Password for non-Mac platforms, and our 1Password extension for Google Chrome are those better ways of doing things.
The last change I want to talk about is a perfect example of security in one area conflicting with security in another. The fact that you can list and sort your Logins by password strength means that you can easily see which of your passwords need to be updated. This is a very good thing for your security, but as we’ve described before, the information by which you can sort data is not encrypted in the current data format.
The security concern here is that if someone captured your 1Password data file, they wouldn’t be able to break its encryption but they could learn that you had a weak password for www.example.com. If they can also guess your username, they could try weak passwords logging into www.example.com. Fortunately, the real threat is far smaller because almost every website limits login attempts. But more importantly, we have been aware of this security trade-off since we designed the current format.
What we have been waiting for to resolve this trade-off is more powerful computers and cleverer programing techniques. Now that we have both, we’re implementing a new approach: starting with 1Password version 3.8.11 on Mac and 1.0.9.BETA-238 on Windows, password strength is not stored in the data at all, but is recalculated by 1Password as needed.
If you sync your data across different versions of 1Password, you may see some oddnesses where you would expect password strength to show up until those versions fully catch up with 3.8.11. That is, 1Password 3.9.2 from the Mac App Store (at the moment) will incorrectly treat the lack of a strength indicator as a lack of strength. So please have some patience with potentially misleading strength indications on versions that haven’t yet caught up to 1Password 3.8.11 with this.
We’ve always known that security is a dynamic process and that we would need make these changes at some point. We remain vigilant about changes in computing and the threat environment so that you can rest assured that your data is safe.