"Belenko said that he himself had been using 1Password Pro, which may be the most-installed password manager for Apple iOS. But he ceased using it after testing the application's cryptography. "When we recovered my master password in five seconds? That was a moment," he said."
I recommend that people actually read Elcomsoft's outstanding report on the security of password managers on mobile devices.
At Blackhat, Andre demonstrated a Chosen Ciphertext Attack (CCA) against PKCS CBC padding scheme. And 1Password (along with pretty much everyone else who used common recommended libraries) did use that padding.
But there is a whole lot more that would need to be put in place for a CCA to work. In particularly you need to be able to ask the app to repeatedly decrypt bogus ciphertext and see how it responds. You need to be able to interact with the thing that is performing decryptions for you.
CCAs are most applicable when there is some encrypted server, and this does form the basis for the BEAST attacks against SSL servers.
Although the CCA didn't pose an immediate threat to 1Password users, we did change the padding scheme in an update to 1Password within weeks of getting to see the report. (It would have been nice to see it beforehand.)
Changing the padding scheme fixes the particular CCA that was used, but the proper way to prevent all CCAs is to use authenticated encryption. Take a look at
There were two other things that they dinged us for.
(1) Our low-security items are really very low security.
We already knew that, but because of how people used 1Password, it was possible for people to have important data that was only protected with the low security 4 digit PIN. In 1Password 4, we no longer have security levels. Everything is high security. (We have introduced a 4 digit application unlock, but that is different.)
(2) Our failure to use PBKDF2 for the Master Password for the native (SQLite) data on the phone.
This was particularly embarrassing because we were early leaders in the use PBKDF2 in general. The history of how we made this mistake is more tedious than its worth, but in general it was part of our transition from using OpenSSL crypto libraries to CommonCrypo in the iOS SDK. The SDK for iOS 3 didn't include PBDKF2 and we were trying to maintain compatibility with older devices. So when we ripped out OpenSSL, we were left without PBKDF2.
Anyway, this was also fixed within a few weeks of the release of the Elcomsoft report.
I really recommend that people read their original report. We don't come out of it smelling like roses, but I think it shows us to be clearly among the best. Elcomsoft does outstanding work, but they also have a habit of stating their results in ways that can be mistaken as suggesting their results are more dramatic than they really are.
I see a lot of your blog posts but not a single place where I can read what exactly you implement in the application I can buy now. I see you write about your "next generation format" that's going to be good etc. And that you write about Dropbox. I don't want to use Dropbox, I'm interested just to see that you really know what you're doing locally for the start.
http://www.informationweek.com/security/encryption/security-...
"Belenko said that he himself had been using 1Password Pro, which may be the most-installed password manager for Apple iOS. But he ceased using it after testing the application's cryptography. "When we recovered my master password in five seconds? That was a moment," he said."