Takeaway: Can passwords be both secure and easy to use? Some think “no”, but if you stop there, you simply aren’t thinking enough.
As noted in “
Don’t be fooled by the argument against unique passwords,” people giving bad security advice claiming that good security practices are impractical and should be ignored seem to be a surprisingly common sight. As the world’s security issues become more prevalent and problematic, the rate of such incredibly bad advice being offered seems to increase, and can do increasing amounts of damage where people buy into their message.
An example from 2007 that I have only just encountered is “
The Usability of Passwords,” which begins:
Security companies and IT people constantly tells us that we should use complex and difficult passwords. This is bad advice, because you can actually make usable, easy to remember and highly secure passwords. In fact, usable passwords are often far better than complex ones.
The underlying assumptions of this statement are several, and almost invariably wrong. First, it suggests that password strength through complexity necessarily makes passwords unusable. Second, it suggests that simple passwords can be “strong enough” for almost all purposes. Third, it subtly suggests — like the majority of such overly facile arguments — that convenience trumps security
all the time. Finally, it suggests that its author Thomas Baekdal knows more about security than people who actually study its intricacies. While this may or may not be true in and of itself (at least in some cases) with no further evidence than the first paragraph of
The Usability of Passwords, the rest of it serves to demolish such a hypothesis when his incomplete understanding of the factors involved in password security is displayed.
Before proceeding, let us demolish his entire argument with a single fact.
Strong passwords are easy to manage
A good password manager solves the problem of password usability quite neatly in at least 98% of cases. In fact, employing a good password manager can actually make password use easier than heeding the simplistic, dangerous advice of most of these advocates for bad password policy. Using one really strong password for all the “important” sites, and one really weak password for all the “unimportant” sites, requires remembering two passwords, where a password manager only requires remembering one; using differing weak passwords everywhere requires remembering many passwords, which does not really make things much more convenient; and using passphrases made up of easy to remember terms in one’s native language requires a lot more typing than a single password for a password management application. Meanwhile, choosing a password manager carefully and configuring the software well can result in a relatively pleasant experience protecting one’s security. The software I typically use is
pwsafe with a keyboard shortcut driven interface for the X Window System — secure, simple, well-designed, and thanks to the addition of my keyboard-driven interface wrapper, it is also very easy to use.
For those using Microsoft’s flagship OS, another earlier article covered
how to use Password Safe on Microsoft Windows 7. In discussion following both this article and the article discussing how to set up a keyboard driven interface for pwsafe, other suggestions of password manager applications were offered.
The incomplete arguments
Much of the problem with non-secure security arguments like Thomas Baekdal’s is an incomplete understanding of how things actually work. Examples drawn from “The Usability of Passwords” are numerous, easily deconstructed, and easily refuted by a more thoughtful individual than its author. Each of them starts with a seed of truth, and proceeds to wander outside the realm of applicability and accuracy when he starts filling in the holes in his understanding with poorly considered conjecture.
How to crack a password
In
The Usability of Passwords, its author explains how passwords are cracked (showing his intimate knowledge of the subject by misusing the term “hack” where “crack” would be correct). He lists five possibilities:
- Asking
- Guessing
- Brute Force Attacks
- Common Word Attacks
- Dictionary Attacks
He (incorrectly, I believe) claims that the most common methods of cracking a password are asking and guessing. While it is true that people asking others for their passwords is probably the most common way that someone might gain access to another’s password, the vast majority of these cases involve honest people who intend no harm and are simply trying to get their work done — or, in some cases, even trying to help the person whose password they acquire in this manner. As for guessing, it boggles the mind to consider the notion that in this age of profitable, computer powered, automated security compromises someone would think that a security cracker sitting down in front of someone’s computer and typing in strings of characters to try to gain access to password protected resources lands within the top ten approaches to cracking password security. Do not let
CSI: New York fool you into thinking that is a common approach, relative to other approaches Thomas Baekdal listed.
The closest we might get to truly common usage of the “guessing” approach he describes — using information about an individual to inform one’s attempts to guess — is using information about an individual to prioritize the potential password combinations used in a brute force attack.
The most sophisticated attacks that actually rely on coming up with the password itself are, in some respects, all brute force attacks. What he terms a “common word attack” is in fact a dictionary attack using a “dictionary” smaller than the Oxford English Dictionary. A dictionary attack is just a way to prioritize a brute force attack so that the most likely passwords to be used by security-unconscious users are tried
first (or perhaps
only). Contrary to his description, in fact, most automated dictionary attacks start with “love”, “god”, “password”, and several other common terms first, rather than just going through the OED in alphabetical order. If the way he described things was accurate, picking “zen” as your password would improve security substantially, while “aardwolf” would mean almost instant compromise (beaten only by “aardvark”, proper names, and initialisms like AAPSS). In the real world, “password” comes before either of those options in the vast majority of cases.
How to protect yourself
Following the rhetorical question, “When is a password secure?” we are treated to some dubious claims. For instance, the first claim made:
You cannot protect against “asking” and “guessing”, but you can protect yourself from the other forms of attacks.
Well beyond dubious, this is quite blatantly false. To protect yourself from “asking”:
Never tell anyone else your password.
As for protecting yourself from “guessing”, Thomas Baekdal himself provided the answer to this problem when he first brought it up:
This is the second most common method to access a person’s account. It turns out that most people choose a password that is easy to remember, and the easiest ones are those that are related to you as a person. Passwords like: your last name, your wife’s name, the name of your cat, the date of birth, your favorite flower etc. are all pretty common. This problem can only be solved by choosing a password with no relation to you as a person.
The next dubious claim immediately follows:
A hacker will usually create an automated script or a program that does the work for him. He isn’t going to sit around manually trying 500,000 different words to see if one of them is your password. The measure of security must then be “how many password requests can the automated program make - e.g. per second”. The actual number varies, but most web applications would not be capable of handling more than 100 sign-in requests per second.
It is true that a security cracker is likely to use an automated process to crack a password rather than typing everything by hand (and here he contradicts his own earlier statements about “asking” and “guessing” being the most common). It is also true that the amount of time it takes to try out enough passwords to successfully select the needed password is effectively the measure of password strength. This claim implies that his rule of no more than 100 password tries per second is invariant and reliable, however. It is not. While 100 per second may be optimistic on the security cracker’s part if his script tries to actually sign in via a Web form provided by a server somewhere out there on the Internet, this is far from the only way to crack a password. In fact, most cases of cracking large numbers of passwords involve someone gaining access to a database of encrypted or plaintext passwords, password hashes, or other server-side login data that allows an offline attack. Utilizing technologies like GPU password cracking frameworks and SSD storage of password hash databases for faster access times, fourteen character passwords have been cracked in around five seconds — much more quickly than the three minutes Thomas Baekdal asserts it would take to crack the password “sun” using a brute force attack. The difference is that in the real world, security crackers are often not so naive as to try to brute force a password via a Web login form.
We then encounter the discussion of how difficult a cracking job is “difficult enough”. The claim is made that a password that takes ten years to crack (using the limit of 100 requests per second described above) is unlikely to ever be cracked. His words:
10 years - Now we are talking purely theoretical.
Even if we choose passwords that take ten years to crack at the rates provided by GPU password cracking frameworks in local attacks with SSD storage for the password hash database, this is not “purely theoretical”. It is actually quite predictably going to take much less time than ten years to crack such a password at some point in the future — possibly as soon as tomorrow, if someone comes up with yet another clever trick to speed up the cracking process. With that in mind, this statement of his becomes so naive as to be laughable:
I want a password that takes 1,000 years to crack- let’s call this “secure forever”.
Maybe, instead of “forever”, it can be cracked in an afternoon when someone invents a new approach to password cracking six months from now. Worse yet,
the rate of technological advancement is accelerating exponentially.
The answer to our prayers is “NO”
After a set of contrived examples of various passwords and their strengths, Thomas Baekdal has set us up for the Big Reveal. The result:
this is fun
He claims this password — actually three distinct, short, common words separated by spaces — takes about 2.5K years to crack. In truth, it takes far less time than that using the GPU cracking methods already mentioned, because it is basically just an eleven word password selected from a set of only 27 possible characters (26 lower case letters and the space character). All he has done is reinvent the concept of the “passphrase”, poorly. Passphrases, loudly touted by many as The Most Secure Thing EVAR, do not in fact increase both convenience and security the way people seem to think. All they do is rearrange the math used to determine how easily a password is cracked.
Tell me — which do you think is more difficult to crack?
If I was a betting man, I would not put my money on "this is fun". It should be immediately obvious that the first is easier just for the simple fact that
this is fun makes use of a set of characters represented by 27 keys on your keyboard with no modifiers (the Shift key, for instance), while
&n" <` O C[ makes use of a set of 86 characters used by a random password generator. To give you an idea of how much of a difference this makes, Thomas Baekdal's example offers 5,559,060,566,555,523 different possibilities from his implied character set, or over five quadrillion. My eleven character password offers 1,903,193,578,437,064,103,936 different possibilities, or almost two sextillion -- almost 20,000,000 (twenty million) times as many possibilities. It gets even better if I want a longer password, because adding just one more character multiplies the number of possibilities by 86.
For anything nontrivial, though, I do not trust an eleven character password, using a character set of 86. Twenty is a reasonably good minimum number of characters today, for only moderately important cases. With a good password manager, I can use fifty character passwords if I want to -- as long as the login system allows them -- and do it much more easily than remembering a different equivalent to "this is fun" for each such case. After a while, anyone might forget which site uses "this is fun" and which uses "my alsatian spot".
That, of course, completely ignores an even bigger problem with passphrases like "this is fun". Sure, it is an eleven character password with spaces in it, but that is not all it is. It is also a
non-random eleven character password. Given that all the words involved are common words, we now face the problem of using a passphrase having done nothing more profound than moving the goalposts a little. Once the kicker gets lined up, aiming is not so much more difficult than it was before the goalposts moved.
From a certain perspective, "this is fun" is just a password with three "characters" in it. The difference is that the "characters" used are taken from a larger character set. A commonly used password cracking wordlist -- the
Openwall wordlist collection -- has four million entries in it, but the majority of these can be omitted when performing an initial cracking attempt against an English-speaking user so naive as to use something like "do the dishes" on Thomas Baekdal's advice. The much shorter, public domain list Openwall offers as a free download contains only 3,158 entries. That is a mere 31,494,620,312 possibilities, or about 31.5 billion. Throw in a few articles, particles, and participles, and you are still
well under 4K words.
If your security cracker is the least bit sophisticated, the script used to crack passphrases will choose words by parts of speech to fit common patterns. Suddenly, 31.5 billion options will become something much more modest. If the cracking script assumes any two words from the unaltered Openwall list, with one of "is", "was", "can", "cannot", "for", "will", "should", "looks", or "seems" between them, your number of possibilities drops from 31.5 billion to a mere 89,756,676, or under 90 million, less than one third of one percent the number of options.
. . . and we are still including non-random, non-word strings of characters such as "2kids", "1022", and "!@#$%^" amongst the "words" that might be used. Really, to use examples of Thomas Baekdal's system for creating passwords, we should exclude a lot of those -- and end up with something on the order of only 2,500 words. That brings our hypothetical password cracking script's first pass through possible passphrases down to fewer than seven million possibilities. Even at a rate of one hundred tries per second, already discarded as naive when someone might have access to a database of password hashes, we are now looking at a maximum time to crack "this is fun" under twenty hours.
That is much less time than the 2,537 years he claims, and I am not even trying that hard.
Catching up with today
Somewhere along the line, someone must have told him about the flaws in his reasoning, because he offered this defense:
You need direct access to the database file or the server to hack something faster. If you got that level of access, you do not actually need the password. You can just look up the data directly.
This ignores a number of factors, including (but not limited to):
- The password hash database might be more accessible than other data; authentication might be performed on a separate server from financial data.
- The user, following the advice of a non-expert like Thomas Baekdal, might use one password everywhere -- thus making a weak password a vulnerability for many other sites.
- As demonstrated, a less naive approach to password cracking than he imagined might actually work within a single day even under his unlikely constraints.
- Password databases on stolen smartphones and laptops could provide password hashes without providing any other data from the server the password might be used to access.
- A flaw in the authentication application could conceivably expose the server to unforeseen work-arounds, and the strength of your password might be the only mitigation.
Other problems may come to mind with more thought. Of course, he takes the defensive measure of trying to exclude offline attacks from his analysis:
What I am talking about in the article is hacking into remote systems (like web apps).
The problem is that the world does not conform to our wishes. Assuming that our passwords are immune to offline attacks just because he decided to ignore them in his Weblog entry is yet another incredibly naive part of his perspective. Simply pushing away the potential problem of server-side issues that may undermine his argument, such as telling us that passwords are easier to crack if the server admins do not add punitive delays when incorrect passwords are submitted, does not in any way make it less of a problem. The fact of the matter is that people implement crappy authentication systems all the time, and sometimes we use those system -- often without even knowing how badly they were implemented on the back end. Choosing passwords that take longer to crack is a way to mitigate the danger of such poorly designed systems. Saying "it's not my problem" when someone mentions that the server might not be set up to look after your security is nothing more than a good way to provide excuses for not caring about your security.
Yes, the server admin should set up a secure system. No, recognizing that fact does not mean you should not worry about it, even if you are not the server admin.
How I learned to stop worrying and love the password
The real reason people hate strong passwords so much is probably that they are being told to use them by people who, while they are a bit smarter about the difficulty of cracking passwords than Thomas Baekdal, are sometimes downright stupid about security policy enforcement. Telling people they should use long passwords containing capital and lower case letters, numbers, spaces, and special characters just makes the technically uninclined sigh and complain. In
"The Usability of Passwords - FAQ," Thomas Baekdal's 2011 follow-up to "The Usability of Passwords," he actually addresses this problem when he discusses why he wrote the original Weblog entry:
The article came to life after yet another discussion with IT, who believed that everyone should be forced to use password with a minimum of eight characters, including two uppercase characters, numbers and a least one special character. I was absolutely furious for several reasons. First, I knew it was like kicking every employee in the groin every morning they showed up for work, that it would do squat for actual security (it is likely to make it worse), and that it would completely destroy the plans I had for password free web application I was working on at the time.
If I had to type in a password like
>9Llz]HX2×8w.5&Go{$k~5pIz&{ every day when I checked my email, another like
Rk~b$icSNGz:+1C8`Vp <-~q@un6O to check my bank balance, something like
gjj-~ixnCs3{/7yS]r(BW#S,q1?9 to log in at TechRepublic, and many more for every site on the Web, I would hate strong passwords too. I type exactly one password for everything on the Web, though. I do not use the same password at every site; I just use a password manager, and let
that remember all those different passwords of mine.
The key to getting people to stop worrying and love the password is to stop telling people first and foremost to use strong passwords for everything. Yes, they should use strong passwords — but they should let the password manager handle it for them. Tell them instead to use a password manager, and to configure it to use strong passwords on their behalf.
For more than 98% of cases, your problem is solved by a password manager, and you should not end up being that guy who posts a lengthy explanation of how little he actually understands about passwords and security, thinly disguised as bad advice that a lot of people might actually follow.
As you can see in Figure C, Google now displays two wheels showing the DBMS and dbms tutorial Wonder Wheels, with the results for dbms tutorial on the right side of the page. You can continue drilling down the tree to further narrow your search. Click the Close button at the top of the results to remove the Wonder Wheel(s).
