Lately there have been several Ars articles discussing passwords and online security. In today’s world, people generally use passwords which are completely inadequate for securing anything, much less private or financial data. Additionally, the “tricks” people are taught on securing their passwords are the wrong lessons (cue obligatory xkcd). So, one of the best solutions is to use a password management system, such as 1Password or LastPass. This solves the problem of weak passwords and the memorization factor, but that still leaves the creation of a strong password for the password manager. A great deal of attention has been given toward creating a strong password, but it is geared toward a computer and not a mobile device. So, how does one create a secure password on a mobile device, particularly in the context of an encryption key.
The Problem
In the above articles, passwords are described as increasingly weak. The xkcd comic describes a guessing rate of 1000 tries per second, but this is assuming no access to the password hash or encrypted data. In light of recent data breaches, lousy security in cloud data providers, and what the NSA’s been up to, this assumption is entirely invalid. The only assumption that makes sense is that the attacker has access to all the data needed to start guessing passwords and does not need to hit a service. In that case, readily available hardware and software is available to literally test password guesses in the billion per second range. This clearly indicates the need for a strong password, but it must also be memorizable or it is essentially worthless. In this compromise, people have developed a whole host of tricks in development of a password, but the truth is these tricks add little to the actual strength of the password. The 1Password Blog has an excellent pull quote on the real security of a password generation technique. Essentially, given a technique, the strength is directly determined by how many unique passwords can be created. This measure, not the number of symbols, not the number of upper case characters, not the number of numbers, not even the password length, is the true test of a password’s security. In information theory, this is the measure of entropy, which is really the only measure that matters.
Taking the first password in the xkcd comic linked above: “Tr0ub4dor&3” used in a system with a simple hash, with an experience attacker, the password would be cracked in less than a second. That not even one second!!! In a system with PBDKF2 with 32768 (number chosen for connivence of the math) rounds or so, then it would last about 4.5 hours. That’s still not very long. Clearly this is an unacceptable password for an encryption key. The xkcd goes on to show an example of a better password, which using the above numbers, would fall in 2.2 hours, and 17 years respectively. This is clearly a much better password but perhaps still not sufficient. As another example, I’ve used a long, non-sensical phrase for a truecrypt password that’s on the order 40-50 characters long. This password can be typed more reliably than the more random looking password that I type several times a day. The reason is that it involves the task of typing real words, of which I’ve had plenty of practice. Strangely enough, the long and very easily much more secure password, will not pass my work’s password requirements, but that’s a whole other story.
So, taking a word that’s more easily remembered, and modifying it using several “clever tricks” results in a less secure and less easily memorized password than 4 random words. That means we should be using a collection of random words for the password management system we use on mobile devices, right? I don’t know about the rest of you, but I could have a hard time typing words with high reliably in an iPhone without the autocorrect enabled (since this is a password field). There’s got to be a better way.
Better Mobile Passwords
I’m going to use the iPhone as my example here, but the same is true of other device keyboards as well. As I stated above, the entropy of the password is the only measure that matters in terms of a password’s strength. The convenience of a password can be measured in terms of how easy it is to remember and how reliably it can be entered. So, to put two of these measures together, I’m going to measure passwords by their entropy per tap on the keyboard (I’ll assess the ease of memory later).
Since I am measuring entropy, this measure is maximized when characters in the password are selected in a truly random fashion. So, this remainder of this assessment is going to assume completely random passwords, with some constraints in the form of the number of different on-screen keyboards. On the iPhone on-screen keyboard, there are essentially 4 different keyboards available. There’s the lower-case letters, upper-case, symbols and numbers, and the extended symbols. Switching from one of these keyboards to another requires 1 or in some cases, 2 taps on the screen. For simplicity, I’m going to assume that a character is selected randomly from any of the keyboards allowed in the scheme with equal probability, and that each keyboard has an equal number of keys (say 26).
Let’s first examine the truly random password using characters available on any of these for keyboards. For any given character in the password, the user will be on the correct keyboard about a quarter of the time. They can get to the correct keyboard in a single tap about half the time, and in 2 taps the remaining quarter of the time. Add in the tap for hitting the actual character and this means that entry of a single character in the password averages 1/4 (1 + 2 + 2 + 3) taps respectively, or an overall average of 2 taps. The entropy of this password is ln_2(26) per keyboard and adding 2 bits for the 4 keyboards brings this to a bit under 7 bits per character. This truly random password results in just under 3.5 bits of entropy per tap.
Moving on to a truly random password using characters available on two keyboards which are interchangeable via a single tap: Examples of this are upper and lower case letters, or lower-case letters and the numbers and symbols, etc… For this password, for any given character in the password, the user will be on the correct keyboard half the time and a single tap yields the correct keyboard in the other half. That means entry of a single character in the password averages 1/2 (1 + 2), or an overall average of 1.5 taps. The entropy of this password is ln_2(26) per keyboard and adding 1 bit for the 2 keyboards brings this to just under 6 bits per character. This results in just under 4 bits of entropy per tap.
Now, using a truly random password using characters available on only a single keyboard. For this password, for any given character in the password, the user will be on the correct keyboard every time. That means entry of a single character in the password averages 1 tap. The entropy of this password is ln_2(26) which brings this to just under 5 bits per character. This results in a bit under 5 bits of entropy per tap.
Summary
| Keyboards | Entropy per character | Average Taps | Entropy per tap |
|---|---|---|---|
| 4 | 6.700 | 2 | 3.350 |
| 2 | 5.700 | 1.5 | 3.800 |
| 1 | 4.700 | 1 | 4.700 |
So, a password that’s secure and easy to type on a mobile device is all lower-case letters? That’s not what is taught in terms of creating secure passwords, but the math doesn’t lie.
Password Length
So, how much length is needed? I’ll refer you to another Agile bits blog entry which discusses entropy and guessing time (scroll down to the table on guessing times). Using this as an example, I’d judge that the password should have at least 50 bits of entropy to start to be considered secure (more if you are worried about the NSA). In the all-lower case letters case, that’s 11 truly random characters. These 11 characters can be entered in 11 taps on the screen, which is far less than what it would take to enter a password that conforms to the typical “secure password” rules. In contrast, “Tr0ub4dor&3” takes 17 taps and is over a million times easier to guess. But what about memorization? Can the average user memorize 11 random characters?
Let’s try it out: Here are some random letters (generated by dd if=/dev/urandom bs=1 count=20 | base64, tossing the non-letters, lowercasing the rest, and finally truncating to 11 characters):
lvwaf osvcs x
Let’s generate a mnemonic. People memorize random factoids with mnemonic all the time, but usually they have a harder time memorizing what the letters stand for than the letters themselves. Fortunately, we only need the letters and that’s all, so our job may be easier. So, for the above let’s try: Leaves Vary Weight After Fall; Operating Systems Validate Computer Science; eXecute; The above took me about 5 seconds to create; it would likely be better if I spent more time on it, but I think the point is made. If this password is something I’ll type a few times a week, I’ll likely memorize it for the rest of my life. I happened to separate the letters in groups of five before I generated the mnemonic (solely to keep count), but don’t be constrained by that count. Use something that can be memorized using as many characters as appropriate for the mnemonic. The mnemonic doesn’t even have to be a true fact; make something up or flat out lie about it. If you see initials you recognize, use a person’s name. Make it scandalous so you smile a little every time you type in that password. If you have a hard time with some combinations of letters, generate another (just be aware that it is technically weakening the strength, but not by much).
Conclusion
So, hopefully this is useful to some of you out there looking to secure your mobile devices or the encryption systems contained with them. I know that all-lower case passwords being more useful is a surprising result, but that is why I went through the trouble to write this. The simple fact is, instead of trying to make a complex password that you have to type on a mobile device, simple use random lower case letters and make up for the reduced complexity by adding length. Going from a complex and purely random password to an exclusively lower case one only requires increasing the length by about 40% to achieve the same strength, but requires fewer taps on the screen.
P.S. If the random letters happen to form a word, or a word surrounded by a few letters, you may want to select another set. While this password is technically as strong as any other, it is only so if the attacker knew you were selecting letters at random. Otherwise, the attackers typically will do a word search first, and this password may fail faster.