Does 1Password Store Passwords Securely?
In ““Secure Password Managers” and “Military-Grade Encryption” on Smartphones: Oh, Really?” Andrey Belenko and Dmitry Sklyarov write quite a bit about a lot of password management tools. This is admirable work, and I’m glad BlackHat provided a forum for it. However, as a user of 1Password, I was concerned to read the following about that program:
However, because PKCS7 padding is used when encrypting database encryption key, it is possible to verify password just by computing KEK (using MD5 hash function), decrypting last block of encrypted database key, and checking if it equals to 16 bytes with value 0x10 (this will be the PKCS7-compliant padding when encrypting data whose length is exactly N blocks of underlying cipher). Thus, very fast password recovery attack is possible, requiring one MD5 computation and one AES trial decryption per password.
As a result of this design issue, password guessing against passwords [stored by 1Password for iPhone] is estimated (by Belenko and Sklyarov) as 15 Million per second. This is the 3rd worst performance out of a group of 11, and 3,000-fold worse than the best performer in the table (Strip Lite Password Manager, at 5,000 per second).
The folks at Agile Bits, makers of 1Password took the time to blog about the paper, and accept the implications of the work in “Strong Security Requires Strong Passwords.”
However, I think they misunderstand the paper and the issue when they write:
The main reason the password can be determined so quickly is because 6 characters provide relatively few possible password combinations.
I believe the main reason for the issue is because of the way in which 1Password has chosen to store passwords. They alude to this further down in the post when they write:
With that said, as Dmitry and Andrey point out, 1Password could do more to slow the password discovery process, thereby making it take even longer. For example, on the desktop (both Windows and Mac), 1Password uses PBKDF2 to significantly slow down attackers. Currently this is not available on iOS as we needed to support older devices. The next major release of 1Password will only support iOS 5 and at that time we will be incorporating these additional defences.
I still don’t think that’s an adequate response. Several of their competitors on iOS use their own implementation of PBKDF2. Now that’s a risky thing to do, and I’m aware that it might be expensive to implement and test, and the impact of a bug in such code might reasonably be pretty high. So it’s not a slam dunk to do so, in the general case. But in this case, it appears that Apple ships an open source version of PBKDF2: http://opensource.apple.com/source/CommonCrypto/CommonCrypto-55010/Source/API/CommonKeyDerivation.c. So the risk is far lower than creating a new implementation. Therefore, I think Agile Bits should change the way it validates passwords, and incorporate PBKDF2 into all versions of 1Password soon.
They also state:
1Password for iPhone will no longer allow items to be protected by just the PIN code. The PIN code was meant for less sensitive items and we always expected the Master Password protection to be enabled on important items. To simplify things, all items will be protected with the Master Password, just like on iPad, Mac, and Windows.
I understand the choice to do this, and move to stronger protection for all items. At the same time, I like the PIN-only protection for my low-value password. Entering passwords on a phone is a pain. It’s not an easy trade-off, and a 4-digit PIN is always going to be easy to brute force with modern CPUs, however much salting and stretching is applied. I’m capable of making a risk management decisions, but I also understand that many people may feel that Agile Bits wouldn’t offer the choice if it wasn’t secure. I respect the choice that Agile Bits is making to force stronger protection on all their customers.
In summary, 1Password is not storing passwords as securely as they could, and if your phone is stolen, or your phone backups are accessed, those choices leave your passwords at more risk than competing products. I don’t think the fixes to this require iOS5. I think the right thing for Agile Bits to do is to ship an update with better protection against brute force attacks for all their customers, and to do so soon.
[Update 3 (April 10) Agile Bits has released an update which implements 10K PBKDF2 iterations.]
[Update 2: 1Password has now stated that they will do this, adding PBKDF2 to all versions for iOS, which had been the only platform impacted by these issues. They have a hard balance of speed versus security to make, and I encourage them to think it through and test appropriately, rather than rushing a bad fix. ]
[Updated to clarify that this applies only to the iPhone version of 1Password.]
Hi Adam,
I’m a team member at SafeWallet Password Manager (http://www.sbsh.net), which was among the 17 password managers tested in this report by Elcomsoft.
Within this list, we’re among the very few password managers that are indeed using PBKDF2 implementation for hashing the user’s password. We’re basically using the exact same encryption used by Strip guys, but we’re doing fewer cycles of PBKDF2. (We got better results from 1Password & Lastpass, but below stripe – which are doing more PBKDF2 cycles than us). My personal feeling (backed with encryption reasons) is that much more cycles doesn’t really give a major advantage here – although it should be increased around 1K. (I’ll be glad to try and dive deeper to this if you would like).
After reading Elcomsoft’s report, I did however had a few remarks which I think are lacking with this report:
(1) Their investigation didn’t review many parts of the encryption implementation by each of the password managers. While they verified which one is encrypting and who isn’t (amazing some saving with plain text!!). They also checked the hashing on the password etc., but they didn’t report other encryption-related elements, such as: proper setup of the encryption initialization-vector, encryption mode used by each of the password managers and a few other similar considerations, which encryption-wise are also very important. Over the years we’ve also parsed the encryption used by some of the competition and we know some do not implement it all properly – so IMO this was missing in this report. (And of course I’m glad to confirm we implemented all of these elements till the very small bit with SafeWallet..).
(2) I think the report is lacking some positive feedback for those that implement things properly. Overall they couldn’t find anything wrong with our encryption implementation (and of course with a few others), but didn’t include any comments on those that use the proper technology and implementation.
(3) As a larger conceptual discussion, the report is ignoring the usability-side experience of the app. The researchers are comparing the security of the app with the device backup. I find it hard to understand how one could securely store his data with a backup on a regular basis and pull information from there?
(4) Last but not least, they assumed users are using passwords containing only digits!!. This really makes passwords far weaker… (as you reduce the number of combinations by far). At least from our side, with SafeWallet, we encourage users to use passwords that include both digits and other characters – this is also why we don’t offer a digits-only keyboard, but force a full keyboard for password entry. In terms of combinations, a 7-char password that includes both chars and digits is pretty much the same as ~12.2 digits only password, so assuming someone is using a 8 or 9 long password that contains both chars and digits (and even better – different letter casing!), the security results is by far far much secure than anything they calculated in this report.
I hope this helps a bit, and of course, I invite you to check SafeWallet! 🙂 Which overall got a pretty damn well results with this report~! 🙂
Thanks for the post, Adam!
You’re right, iOS 5 is not required for PBKDF2; the chief reason it wasn’t added was so we could support older iPhone users. I was planning on waiting for 1Password 4 to add PBKDF but because of your concerns and comments from others, we’ve decided to add it to a 1Password 3 update later this month. We’ll try to find a way to reduce the number of iterations for older phones so they remain responsive.
We will also be removing the padding Dmitry and Andrey discussed which will double the effort required to brute force the master password.
Together these changes will help a lot, but as you pointed out, a very short password can always be brute forced relatively quickly. A strong master password is still your best defense against would be attackers.
—
Dave Teare
AgileBits Founder
Hi Adam, I’m Stephen from Zetetic, the makers of STRIP (http://getstrip.com [link no longer works] ). It was the app noted as most secure and “by far the most resilient to password cracking” in the ElcomSoft presentation.
This paper is especially important because it exposes a range of serious issues, from apps that don’t even encrypt data, to real flaws in crypto implementations. It also underscores the fact that, for most apps, as a user you have NO IDEA what they are doing with your data. This is the main reason why we open sourced the secure database in STRIP, called SQLCipher (http://sqlcipher.net). This provides complete transparency about how the app deals with security for users that are interested in the details.
The other issue it raises is that many apps take the approach of “good enough” security. This is dangerous. It’s clear that adding key strengthening (PBKDF2) does have a significant effect on cracking speed, yet many apps skip it, or use too few rounds (‘100 iterations should be OK’). There are highly competent companies like ElcomSoft, or other less reputable organizations, that make it their business to break good enough security. Users place their trust, and their most private information, in the hands of App developers who author security software; that is a serious responsibility.
STRIP uses 4,000 rounds of PBKDF2, and has since iPhone OS 2, in 2008. Most folks think this is overkill, but it’s clear just how important it is when you look at the numbers Elcomsoft compiled. In the next major release of STRIP, we’ll increase that even further, and switch on a new HMAC page protection feature that will make Strip’s databases tamper evident. This paper has also sparked a lot of interest in STRIP from people who take security seriously, so we’ve started to release converters from a few other programs (http://getstrip.com/switch [link no longer works] ).
Finally, the choice of password is very important and a key factor in the overall security of any crypto system. Regardless of the application used, numeric PIN numbers are not safe. There is just not enough entropy in a numeric passcode to make brute force attacks infeasible. With a fast GPU an 8 digit numeric PIN could take only a few hours to crack, whereas a random alphanumeric password with meta-characters of the same length would take thousands of years. Choosing a strong key will go a long way toward making your data secure, when used with a trustworthy application.