Having shed light on the specificities of free password managers for iOS, Dmitry Sklyarov now focuses on the popular paid password apps for this platform.Now that we have reviewed free password applications, it’s actually fair to assume that paid apps should be better than free ones. They should protect data, because you could see that, maybe except the last one, all free ones are not really good at data protection. So we just searched Google for good reviews about password keepers for iOS devices. We found several of them, summarized the results on those, and chose six very popular password keepers for iOS. One of these applications, called SafeWallet, actually has versions for a number of desktop and mobile platforms (see left-hand image). Unlike most apps of this kind, it uses its own proprietary database file format which is common for all platforms, so you don’t transfer your data – you just copy the file from one platform to another, and still have access to all your passwords. Inside this application, the master key is encrypted with master password that you provide when trying to open this app. The password is derived by PBKDF function with 10 iterations – again, that’s better than 1, even better than 3, but it’s still a very small number. So, testing speed is pretty fast for GPU and for CPU. Next one is called DataVault Password Manager, it’s actually a very popular one. It uses keychain for storing all sensitive data, so all passwords are encrypted using a key, and then stored in keychain using the protection implemented by the operating system. It’s a good idea to store information in keychain, and for password validation (SHA-256) the hash is stored inside the keychain. The keychain is not easily accessible, so to get the hash value you must bypass some security measures from the operating system (iOS). Therefore, if there is passcode protection on the iOS device, you need to find that passcode before you can extract data. I’m not sure why, but the authors of this particular application chose to store that hash value not in the data field of the keychain item; the data field is always encrypted, it’s the main items of the keychain record that should be protected. But on iOS 4, all the other attributes are still stored in plaintext, so if you have iOS 4 on your device, SHA-256 hash of your password will be stored in plaintext. Therefore you don’t necessarily need to have the passcode to extract that value. That makes quite a broad attack surface. But in iOS 5, Apple helps developers and users protect their data by starting to encrypt not only the data field, but all the other fields too. But to implement search capability for keychain items, iOS 4 stores the hash of plaintext value near the encrypted value for every attribute. So, for now we have password hash encrypted, and SHA-1 hash of password hash stored in plaintext inside the keychain. So again, we don’t need to find the passcode, we can just add one additional SHA-1 computation to start our attack. Therefore, using keychain is good, but it’s used improperly. The attack is very fast; again, no randomness; and it’s easy to build rainbow tables for attacking such application. Another password keeper I’d like to talk about is mSecure. Again, it’s a very popular password manager; all the data is encrypted with Blowfish algorithm. There is no complex computation, the fixed key is stored for validation, so you just need to decrypt it and compare with the original value. An attack requires only one hash and one Blowfish calculation. Again, we don’t have Blowfish optimized for GPU, so the attack speed is relatively low, but if you spend some time on GPU optimization, it will probably be increased a lot. The next application is LastPass. It’s kind of about services, so you get the application for free, but to use it you need to subscribe for LastPass service that stores your information somewhere on the Internet, and it’s accessible from any of your devices. After synchronization, after logging into this system you will get a local copy on your device. It uses a master key derived as hash of username and password, and again, the entire implementation is very simple, there are no multiple iterations, so the attack speed is very high, and no good protection is provided by this application. Next one is probably the number one password keeper on the market, called 1Password Pro. Quite a few other platforms are supported by this application, and it’s really popular. A colleague of mine had been using it before we started this research, so we had some additional feedback on it. This application allows you to use two different types of protection for different classes of data, so less significant data is protected by PIN which is usually shorter, and the most significant sensitive information is protected by password of any complexity. All the data is encrypted with Advanced Encryption Standard (AES); even 128 bits is enough, in my opinion. The key is derived from the PIN or password using algorithms represented in the top of this slide (see image). You can see that there are many steps of computation that are necessary to correctly validate the key. So you need to calculate the encryption key as MD5 hash function; you need to calculate the initialization vector as another calculation of MD5; you need to decrypt the database key; then you need to decrypt the validator using that database key; and finally, you can do the comparing.
But actually, you don’t need initialization vector because you don’t need to decrypt the first block. Thanks to PKCS7 padding, you need to decrypt only the last one, and the initialization vector for the last block is cipher text of previous block. So you can just remove the separation from the password cracking procedure. And actually, you don’t have to decrypt the validator, because, again, PKCS7 padding allows you to reject wrong keys after decrypting the database key. Therefore you can simplify this algorithm by factor of 2 by simply removing unnecessary operations. So we got very high cracking speed and not very good protection.The last application in our review is SplashID Safe. It’s maybe number two or three in many ratings. There are lots of people using it all over the world. We looked only at its version for iOS, so I don’t know how exactly protection is implemented on other platforms. But on iOS, all data is stored in SQLite database and protected with Blowfish (we already encountered this algorithm a bit earlier in our talk). It’s not very fast in terms of cracking due to absence of GPU optimization, but it’s not that bad – it’s just not very good. The master key is used as Blowfish key, and Blowfish key can have arbitrary length, not fixed length. I don’t know why, but the master password is stored in database encrypted by some key. It could actually be called random key, by definition of XKCD (see image). This time, the random key is really random, it’s not some easily guessable word, but it’s hard-coded in the application. So, every user of “SplashID Safe” for iPhone has a master password encrypted with the use of fixed key, so you can in a matter of seconds extract your data from the database, decrypt the record with fixed key, and obtain the master password. And then, using that master password, you are able to decrypt everything else in this database. Actually, this is very bad for the industry because security not providing security is not a very good thing.