Andrey Belenko and Dmitry Sklyarov, security researchers representing Elcomsoft Co. Ltd headquartered in Moscow, give a presentation at Black Hat Europe event to raise relevant issues of data protection on smartphones.
We would like to welcome you on our talk at Black Hat Europe 2012. Today I’m here with my colleague Dmitry Sklyarov. My name is Andrey Belenko.
We work for the company called Elcomsoft which is based in Moscow, Russia. We mostly do software development for computer forensics, and password recovery tools. And today we would like to present our research which will analyze the security of password keepers, password manager applications on modern smartphones. So, let’s start.
Today we will start with a short overview of authentication: how it’s done on computers and how it’s done on smartphones. We will then proceed to establish the threat model under which our research was done, to see what the threats are and how we can exploit them. After that we will proceed to actual analysis of BlackBerry password manager applications and iOS password managers. And then we will present you some information to conclude, some summary information about our findings so that you can have an idea of the state of security in this field.
Authentication: PC vs. Smartphone
So, let’s talk about authentication. On conventional computers like PC or desktop Macs, there are a number of options which are available for developers to use as a means of authentication. First of all, this is the Trusted Platform Module which is a piece of secure hardware installed on computers, on some of them. What it basically does is it authenticates the hardware before performing some sensitive operations such as decryption. So, if you just change the hardware and introduce some malicious part to it, it will not pass the authentication process.
The second means of authentication is something more traditional, it is biometrics, which is something you are. Again, on computers it’s fairly easy to buy a fingerprint reader or something like that, and to integrate this into the authentication process. We are not talking about the reliability of this authentication; the point here is that it can be done on desktop computers with relative ease.
The third way to perform authentication is SmartCard + PIN. It is something you have and something you know, or, as one of my friends says, something you know and something you usually leave at home. Well, again, SmartCard readers are cheap; there are products, solutions that can help you build a corporate environment for two-factor authentication, so it’s possible to do this on desktops.
And the last way – it’s probably still the most popular one and still the reason why our company has some business – is password and passphrase authentication. It’s used everywhere, and I’m not sure if I need to talk about this in more detail.
Well, on smartphones the situation is very different. You don’t really have TPM or biometrics, or SmartCards on smartphones, because most of them are pretty restrictive in what you can do, what you can run, and what you can connect to them. So, pretty much the only means of authentication that is applicable on smartphones is PIN, password or passphrase. Well, here I would like to just give a short note about the Trusted Platform Module. Technically speaking, most of the modern smartphones have some secure co-processor inside them, for example the iPhone. But the problem is that application developers cannot talk directly to this co-processor – so the system can, the applications can’t. Applications cannot use this secure piece of hardware to enhance the level of protection. So essentially, there is no such thing from software developers’ perspective.
Therefore on smartphones, we’re pretty much left with passwords, passcodes; and the pattern lock looks different from the passcode, but essentially there’s a numeric password. In this example the corresponding password will be something like 1-4-2-5-6-9-8 – the numbers defining the route you swipe as you follow the pattern. So, password is the only common and reliable way of performing authentication on smartphones, but there are problems associated with it.
The first problem is that typing passwords on a smartphone is a pain. On PCs, on laptops you have full-sized keyboard, you can utilize your motor memory; well, I’m pretty sure that everyone who is using random or semi-random passwords cannot spell them if they are asked to take a pen and spell them, but they can type them in. With me, this is the case: I don’t know my passwords, I mean how to spell them, but I know how to type them. Again, it’s relatively easy to memorize long and relatively complex passwords on full-sized keyboards using motor memory.
With smartphones, it’s a completely different story. Touch screens do not give you the mechanical feedback to fingers, so you really need to look where you type, and this complicates the process, making it more difficult to use long, and especially random passwords. So, it’s okay to type a word but, again, how many errors do you make even when you’re texting? The spell checker always replaces the typos, you probably don’t notice them sometimes; but if you enter a password, the spell checker will not fix the password for you, so it’s much more difficult to use long and complex passwords on smartphones, especially on smartphones with touch interfaces. On BlackBerries with the small keyboard it’s somewhat easier because you still have some mechanical feedback, but it’s still much more difficult than on full-sized keyboards.
So, we believe it is fair to assume that passwords on smartphones will be shorter than their counterparts on PCs, if used by the same person.
Password Cracking
Next problem is password cracking. People who want to crack the password are usually smart guys, and they will utilize the most powerful platform they can find. I mean, if the password they want to crack protects some data on a smartphone, it doesn’t mean that the attackers will use the same smartphone to perform the actual cracking. They will offload the computation to more powerful processors, to CPUs, to GPUs and so on, and this will increase their chances to crack that password. The problem here is that the passwords are usually used in a way that there is some encryption which is based on the password, and the encryption key is computed from the password. Usually it is computed using some complex cryptographic transformation, like performing 1 Million hash iterations. And there is a problem when you try to do this on a slow platform like for example BlackBerry, because the CPU is slow, and you don’t really want to create a program which will take five minutes to verify the correctness of the password. But really, the way to avoid this is to reduce the number of iterations to make this password-to-key transformation less complex. But at the same time, this will lead to faster password recovery attacks on more powerful platforms like PCs.
So, we have a challenge here: on the one hand, we need to reduce the complexity of this key computing function to make it usable and make the interface responsive on constrained platform like smartphone; on the other hand, we need to make password recovery slow on fast platforms like PCs with fast CPUs and GPUs. Today, with things like iPhone, A4 chips and A5 chips, this is less of a problem, but a few years ago (and still with BlackBerries today) it was a problem. And like I said, the attackers are smart guys. They can always use GPUs or distributed computing to make password cracking even faster. In this presentation, you will even see some indications of how fast GPU password recovery may be.
Authentication Wrap Up
So, let’s look into some more things about authentication. On computers, you usually do not enter you complex, long passwords too often. Typically, when you start your working day you log in to your workstation, you continue working until break, then you lock your screen, go to lunch, return, unlock your screen, continue working, and so on. We think this is a typical scenario. It may be five, maybe ten times a day that you need to enter the password on a PC. With smartphones, it’s a completely different story. You need to enter the PIN or passcode every time you want to make a call, read a text, send a text, read an email, send an email, and so on. This forces people to use shorter passcodes, I would say. At the same time, handling passwords on smartphones is more difficult than on PCs for the reasons I have explained above – because you need to have a high level of protection with fewer resources. This is the problem.
Threat Model
Let’s now move to the threat model. Throughout the research we assume that the attacker has physical access to the device, or the attacker can read the backup files of your device, or the attacker can in some other way access the files that comprise the password manager database. We believe these are fair assumptions, and I will try to explain that a bit later. And the objective of the attacker is essentially to get your passwords from your password manager database. It may be recovering the master password for your password keeper, or just decrypting the database itself. And I would like to point out that we will focus only on data at rest; we will not analyze the networking functions, the exploits in the password manager applications. We will solely analyze the data at rest – how the program handles encryption of the data stored on the device.
What about physical access? Well, there are lots of computers stolen every year, and also there are lots of phones stolen, left at the bars and so on. Since a typical phone is much smaller than a typical laptop, again, it’s much more probable that you will lose your phone than it is that you will lose your laptop.
So, let’s now talk about device backup. Both iOS and BlackBerry platforms provide a user with the opportunity to create device backups. Device backup contains a lot of sensitive information. Apart from passwords and databases of password keepers, typical backup contains information about email accounts, texts, call logs, pictures, application data – lots of sensitive stuff. This is the reason why both platforms have some protections to guard your backups.
On Apple iOS, to be able to create a backup you need your phone to be unlocked. This can be done either by entering your passcode on the phone, or if your phone is already paired with a computer on which you are trying to create a backup. Also, there is optional encryption of the backup, and on the iOS platform we believe it is done in a proper way, because encryption is enforced by the device. So, once you configure your device to produce encrypted backups, it will always encrypt a backup before sending it to the computer.
To disable this encryption, you will need to specify the original backup password which you had entered. This backup password is only requested when you try to restore from the backup, not when you create a backup. This actually creates a usability problem for many users. For example, when half a year ago iOS 5 was released it was initially released in a version where you couldn’t update the operating system, you needed to do device restore. So, essentially, everything is wiped out from the device, and then iTunes restores your last backup on the initially installed iOS 5. This created problems because many users turned out to have had backup encryption switched on at some point in the past, but since they are not asked for the password they just don’t remember it. And there were lots of people saying something like: “iTunes has a bug, it switched on encryption on its own, I never specified the password,” and so on. And when you ask these people some questions, it turns out that the password was 1234, or their cat’s name, or their neighbor’s name. We have difficult time explaining to them why iTunes knows their cat’s name.
On the BlackBerry platform, backup encryption is pretty much the same, in that you still need the device password for BlackBerry to be able to create a backup. It is not possible to pair a BlackBerry with a PC, so you will need to enter it every time you create a backup. There is also optional encryption of the backup, but it’s done in a somewhat strange way – it is not enforced by the device, it’s performed by the desktop application. So, if you have a BlackBerry device and you know the password, the backup encryption will not be a problem for you because you can just bypass it, instruct the desktop application not to encrypt anything. But still, if you only have the encrypted backup then you need to recover the password, and this can be quite difficult because there is really slow transformation involved.
If you don’t have the backup but you have the device, there are some scenarios where you may be able to obtain the required files from the device itself. On iOS platform this is possible through three different ways.
First of all, you can use the AFC protocol via which iTunes talks to the device when it syncs applications, that kind of thing. There are programs that can access the application sandboxes on the phone and transfer files between the phone and your PC, so you can pair your phone with the computer to transfer certain application folders.
Well, of course we still believe jailbreaking is a bad thing because it reduces security, so if you have a jailbroken phone and there is an SSH server running, you can access pretty much every file on the device remotely. It’s also possible to obtain files this way.
It’s also possible to get the required files through mobile forensics way of doing things, which is called physical imaging. When you obtain a bit-to-bit image of the iPhone disks, again, you can decrypt that and get the required files.
On BlackBerry it’s more difficult because, again, there are solutions to perform physical imaging of BlackBerries, but they all require device password. So, on BlackBerry platform it’s up to device password: whether you know it or not. On Apple iOS there are different scenarios.
BlackBerry Password Managers
So, enough for the background, let’s do the actual application reviews. Let’s start with BlackBerry. We will consider two applications. The first is BlackBerry Password Keeper, it was included with OS 5, I believe. And the second application is BlackBerry Wallet.
Let’s have a look at BlackBerry Password Keeper. If you know a little about password cracking, you probably know that three iterations of PBKDF2 is not much, and that password recovery will be very fast. In this case, we have three iterations of password-based key derivation function with SHA-1 hash, and the data inside the database is encrypted, it’s okay. So, if you just have the file you cannot read the stored passwords in plaintext, but still you can mount a password recovery attack which will be very fast, it’s about 5 Million passwords per second on a modern CPU, and up to 20 Million on GPUs.
There is one quite interesting thing which we can exploit in many different password keeper applications, and this is actually the PKCS7 data padding (see image). So, what is this about? When you encrypt data using the block cipher, you can only encrypt data in chunks, and the size of the chunk is the size of the block of this cipher. For most of the modern ciphers, the block is 16 bytes. And the data must be padded before encryption, it must also be padded in a way which will allow removing the padding after decryption, so you need to somehow store the length of the original data explicitly or implicitly. There is a standard for this, which is PKCS7 – well, part of standard defining the padding. The standard says that you need to add to your plaintext data a certain number of bytes, so that the length of your data plus the length of the padding will fit evenly in the block of the cipher, so all blocks will be completely filled. The value of the byte which gets appended to the data is equal to the number of bytes that get appended.
In the first example on the image, the grey area is the plaintext data which we want to encrypt, and numbers 7, for example, in the first line are the bytes, each byte having the value of 7, and we have 7 of them – this is how it works. There is one special case when our plaintext already fits evenly in the block size – in this case we just add an additional block consisting of padding only.
What this allows us to do is quickly reject wrong keys. So, when we’re trying different keys and performing decryption, we can actually decrypt only the last block and check if the padding is correct. In the worst case scenario, if there is only one byte of padding, this will give us the survival rate of keys of 1 key in 256, which is actually very good. This padding essentially provides some sort of known plaintext attack, limited but still…And a great thing is it allows gaining better password recovery rates. This trick is used for many different applications in our research.
BlackBerry Wallet is our second application to be reviewed. There are two versions. Version 1.0 was used with OS 5; it was not included with the operating system, but it was a free download from the App World, I guess. This one is pretty straightforward. It stores the double hash of the password; password verification is very fast: 6 Million on CPU and about 300 Million on GPU. This is actually very fast, and I’m not sure why “Research In Motion” did this. Again, there is no randomness, no salt involved, so if you really want to do this fast you can always build Rainbow Tables for this particular type, and recover passwords in minutes and seconds.
Version 1.2 was a little different, it’s definitely better than Version 1.0, but still it’s not good enough, in our opinion. It took the approach similar to that of the Password Keeper, so it is using the PBKDF2 with a random number of iterations – between 50 and 100. I’m not sure why it’s still using that amount of iterations, but still it’s much better than 3. The estimated recovery speed is 200,000 on CPU and about 3 Million on GPU. By today’s standard, this is very-very fast. Just to give you an idea, password cracking for Microsoft Office 2007 documents is like 1000-5000 passwords per second, so it’s nowhere near millions. And here we have devices with a small keyboard, where you cannot really type a complex passphrase, and the recovery speed of millions of passwords per second. This is basically it about BlackBerry password managers.
iOS Password Managers (Free)
Actually, there are lots of applications available for people in the App Store, and we’ll start with free ones. Just type “Password Keeper” in App Store search, and you will get a lot of results – actually, there are hundreds of them. Then you can choose several applications that are claimed to be free password keepers, or something close to password keepers. Here is a short list of those applications (see image). We will discuss each of them a little bit closer.
![[un]Safe Triplets – 3 apps, same filename](https://privacy-pc.com/wp-content/uploads/2012/12/unsafe-triplets.jpg "[un]Safe Triplets – 3 apps, same filename")
Those three applications are not ‘alone’ in the App Store. The next one I’m going to review is iSecure Light (see details on the image). Again, it involves no encryption at all. You can see the filename looks like some template name, or some name from a code sample, so obviously people just don’t invest much effort to make the application unique, they just slightly modify it and put it on App Store. Actually, lots of people are downloading it – it’s one of the top results in search. Again, all the information can be extracted just by direct query to the database.
The next application is not really positioned as password keeper; it’s some program to manage access controls to some files stored on an iOS device. It’s called Secret Folder Lite. Again, all the data is in plaintext, there’s no encryption, and it’s very easily extractable.
The next one I will talk about is a free counterpart of the application called Ultimate Password Manager, and the author of that application honestly notes the difference between the paid and free version. Free version doesn’t protect your data, so it’s a password keeper that doesn’t protect your data because it’s free. I’m not sure if someone would actually need a password keeper providing no protection.
Now, one of my favorites – it’s My Eyes Only™ – Secure Password Manager. It promises a lot of benefits to the user. It uses NSKeyedArchiver format which is common for Apple solutions. This one encrypts all private data with RSA asymmetric encryption, which is considered a standard for good security. This sounds pretty impressive. It stores the private key, as well as the master password, in keychain. Storing sensitive data in keychain is a very good idea for iOS, because keychain items are protected by the operating system, and there is no easy way to extract all data. There are other ways, but they are not so easy to implement here as for the applications I reviewed a little bit earlier.
I believe using RSA and storing private data in keychain is an attribute of a good application. However, the length of the key is only 512 bits. By the way, the first time RSA key of such length was factored was in 1999, so it’s 13 years ago. At the time, it took a lot of computation power, but now it could be solved in a couple of days on modern computers. The funny thing about using RSA is that the private RSA key is stored inside the data file along with protected data, so secret is stored near the key. I don’t know who invented this, but it looks really funny to me.
The next application is Keeper® Password & Data Vault – again, we have military-grade encryption here, it’s really strong. This application uses MD5 hash to validate the password. The hash value is stored inside the database and can be easily extracted from the database. It also uses SHA-1 hash as encryption key for AES algorithms. MD5 is actually a commonly used hash function, but it’s not too good because there is a collision built for MD5 many years ago. But MD5 is like a platform for testing skills on GPU acceleration: many people try to compete with each other by implementing a fast way of cracking MD5 using GPU. Also, there are a lot of rainbow tables already built and available for free for downloading online, allowing you to get the password by its MD5 hash in minutes. The easiest way to attack such hash is to just type a hexadecimal value of your hash in Google, and in many cases you will find the password in fraction of a second. So, cracking such type of protection can be lightning fast, which is why military-grade encryption doesn’t help in this case.
Another application is Password Safe – iPassSafe free version. This is the only application out of the ones we analyzed that tries to prevent using easily guessable passwords, so when a user tries to set a weak password, the app alerts them that this password is very easy to brute-force by fingers, so it’s better not to use it, and it doesn’t allow setting this password for protecting the password database.
But encryption is performed in a very funny way: we have a password that’s just padded to length of 32 bytes (256 bits) and used as an AES key. That key is used to encrypt the master key, which is then used to protect all data. There is an encrypted string for validation inside the database, but actually this application uses PKCS7 padding again. So, after decrypting the key you should have the last block completely filled with value 16, because AES uses block size of 16 bytes and the key of 32 bytes (it’s two blocks), and an additional block is added, so we just don’t need to decrypt the key to verify the password. We decrypt only the last block and check its value; if all bytes have the value of 16, we find the correct ones. So, attacking this type of protection requires only one AES encryption, setting the password and decrypting one block, so it’s really fast. As of now, on GPU we have the speed of about 20 Million, because we don’t have optimized implementation of AES encryption for GPU, and probably if we spend some effort to doing so (as we did, for example, for MD5 or PBKDF key derivation function), the rate of password testing will be increased by 10 or 20 times. And again, this application does not use any randomness to generate encryption key from the password, so it’s possible to build a rainbow table and use it to attack the data at a very fast rate.
The next application is Strip Lite – Password Manager. Again, it has both free and paid version, the difference being in the number of passwords that can be stored. And to be honest, this is the best one out of all password managers we tested during our research. It’s straightforward and simple. It just uses PBKDF with 4000 iterations – that’s very close to the number of iterations used by WPA authentication on wireless networks. You can look up speed testing for WPA on the Internet, and you will get the same speed for this application, although this app is a little bit easier crackable than WPA. But honestly, 4000 is a good decision for mobile device, and definitely much better than most other solutions.
By the way, this application works in a slightly unordinary way. It doesn’t protect individual records inside the database – instead, it protects the entire database. Therefore the whole database is encrypted. Furthermore, the open-source component developed by the same company (Zetetic) is perfectly available at the source level, so it’s not too problematic to figure out the number of iterations and the algorithms utilized to enforce security in this particular password management application for iOS operating system.
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.
Now I’m going to move on to summary and conclusions. We mentioned iOS passcode many times during this presentation, and it’s probably a really good example of how passcode, or password protection, can work if you know what you’re doing.
On iOS, starting with iOS 5, your passcode is involved in protecting your secrets: it’s not just verified, it’s used to generate the so-called passcode key, and without that passcode key it’s impossible to decrypt the secrets stored within the device. Passcode derivation function is implemented using hardware AES encryption which is embedded in every iOS-based device: iPhone, iPad, iPod, and so on. And every device has its own unique key, so to calculate the passcode key from the passcode, you need to run the code on the device. You can’t scale it by using multiple devices simultaneously; you can’t use GPU because you don’t know the exact process, exact key used by the device when you go from passcode to passcode key. And speed for iPhone 4S is about 6 passwords per second, that’s not too much, and even a 6-digit passcode can’t be tested faster than in 24 hours. This is very good in comparison with all the other password keeper applications that we looked through during our presentation.
Here is the final summary table (see image). There is a lot of statistical data, but the most significant is the last column. We measured the number of digits that comprise the password which could be brute-forced during 24 hours for some of the password keepers: the smaller the number, the better protection. You can see that for most items the level of protection is about 12-14. It means that you need to have at least a 14-digit password to not be crackable in 24 hours. It’s easy to convert arbitrary character, not only digits. There are 95 characters on standard English keyboard, so it’s about 100 of them. You can just divide the number in the last column by 2 and get the length of any character password that could be cracked in 24 hours. For example, for Keeper® Password & Data Vault you need to divide 14 by 2, so 7-character password could be cracked in one day using one computer, and you can use a lot of them simultaneously if you have enough resources.
iOS passcode is not vulnerable for scaling, for GPU optimization; and even without optimization it’s much better than everything else. So it’s a good idea to use passcode protection on iOS device and not invent anything else.
Now, a few words to conclude on the whole research. None of the tested password keepers offers something better than is already offered by the operating system. If you are using your password keeper on a device that could be stolen, or the password database could be extracted from the device, your data is vulnerable. Paid applications are not necessarily better than free ones. In our review, the best one is a free one.
And finally, a kind of wishlist for all users. Always use passcode, and for iOS devices use something more complex than a standard 4-digit passcode, because unless you have iPhone 4S that is for now not vulnerable to boot-level jailbreak, 4-digit passcode can be brute-forced in less than 2 hours (for any device prior to iPhone 4S). Don’t connect your phone to untrusted computers even to charge it: there are attacks where acquiring data via USB can be performed. Never jailbreak your iPhone on your own, because by doing so you can make it vulnerable to a wide range of attacks.
And some recommendations for developers. It’s not too easy to implement good crypto without really understanding how security works in deep detail. Most people who develop password keepers, I believe, are very good programmers, but they need to learn how to implement security and start their way from the operating system, instead of inventing something else. And finally, we want to thank our partner from a UK law enforcement agency who initially asked us to check how hard it is to crack access to SplashID databases, because they have such database in some of their cases. That was the initial punch for our research. We evaluated the applications and found many interesting things, and started going further, and now you can see the results.
Thank you for your attention!
