Recently, one of my colleagues forwarded one of those memes currently circulating through social media about the joys of password authentication, with the thought that it might offer a way of mixing advice and humour. In this case, the meme takes the form – slightly exaggerated, but maybe all too close to reality in some cases – of a service user’s attempts to create a password acceptable to the service's authentication mechanism, with the user’s increasing frustration expressed through the increasingly vulgar passwords he tries to create in order to meet the increasingly .
As it happens, I have indeed used that same meme in an informal context for much the same purpose. However, there are legal ambiguities about copyright/intellectual property issues and the use of internet memes – and in any case, this is a family-friendly blog! – so I’m going to stick to my usual practice of not reproducing material when I can’t determine its copyright status. (Sorry about that: it is actually quite amusing. However, there is a rich seam of similar material here and here.)
In case you were wondering, meme-like material in my blogs like this one, used in a recent blog on a related topic, is usually self-generated. You may or may not like my memetic meanderings, but it saves me contravening the terms of terms of service like these.
But let’s consider what memes like this really tell us about password authentication requirements and how people react to them. There are issues that crop up in this and similar memes: some are more irritating than others, and some are more justified in terms of enforced security than others. For instance:
- minimum password lengths
- password aging (mandatory changing of passwords after a set period)
- mandatory mixed case
- mandatory mixed alphanumeric characters
- mandatory interpolation of ‘special’ (non-alphanumeric) characters
- rejection of passwords that have been used previously
- rejection of passwords that match a list of over-used passwords
- rejection of passwords with appended numerals
- restrictions on repeated characters
Fernando Corbato, the MIT computer scientist who is widely credited with pioneering the use of the password as a means of logging into a computer says passwords have now become “kind of a nightmare.” Corbato said in an interview with Wall Street Journal’s Digits Blog that he himself had around 150 passwords, and now committed security sins such as writing down a “crib sheet” to remember them all. He went on to say that“I don’t think anybody can possibly remember all the passwords that are issued or set up. That leaves people with two choices. Either you maintain a crib sheet, a mild no-no, or you use some sort of program as a password manager. Either one is a nuisance.”
Well, yes. Secure authentication is an inconvenience, like most security measures. Let’s take that as read.
Password length still has some bearing on the effectiveness of a password, though when a bad guy is able to throw a full-strength password cracker at your login, it doesn’t necessarily make much difference whether your password is six characters or eight characters in length. If your eight-character password is ‘password’ it probably makes no difference at all, because it doesn’t take long to run a dictionary attack that includes all the classic over-used passwords. Even lengthy passphrases can be (and are) vulnerable to some dictionary attacks. It is, after all, as easy in principle to include a clichéd phrase in a dictionary. But there’s more to this than dictionary attacks.
Here’s an issue I revisited in a recent presentation.
ocl-Hashcat-plus version 0.15, released almost a year ago, can generally accommodate passwords with lengths of 55 characters or more, depending on a number of variables. I imagine that this kind of technology has moved on since that release. The kind of algorithms that can achieve this kind of performance are slower and more resource-intensive, but achievable.
Passphrases can offer better protection against password cracking than a simple password, but many of the techniques used in password cracking are perfectly usable when trying to crack a passphrase, even though in many cases they’ll take significantly longer. Fuzzy matching algorithms can catch simple-to-fairly-complex variations. Common techniques for improving entropy such as character substitution (for and by spaces/delimiters, punctuation etcetera as well as words) work as well on long phrases as they do on short strings, but so do the techniques for countering them.
Basically, however good your passphrase is, unless the service severely restricts the number of login attempts that can be made with an incorrect password, you should assume that your opponent is a system with infinite patience and the ability to try huge numbers of variations per second, not some movie star making smart guesses at what keywords might appeal to the villain du jour. If the attacker isn’t restricted in the number of cracking attempts he can make, as when a password database is compromised and captured so that it can be analysed offline, it’s more about what resources he can throw at your passphrase than it is about how many characters you used. This has always been the case: all that’s happening with a tool like Hashcat is that the difference in crackability between a six-character password and a 50-character passphrase is remorselessly narrowing as more cycles and better algorithms become available.
There are a few things you should bear in mind, even as you consider how (and whether) you should improve your password practice:
It doesn’t matter how good your password is:
- If the service you use it to access is compromised – you can’t do much in that case except hope the provider lets you know there’s a problem so that you can take appropriate action.
- If you inadvertently give it away (for example, in response to a phishing email)
- If it’s a password you also use for another service and that service is compromised. Which is why we tend to tell you not to share passwords across different services, though it may not be such a big deal if you only do that with services that don’t matter (more or less by definition), as discussed earlier here. The fact is, though, if you know when it’s safe to re-use a password across services, you don’t need my advice. For most people, it’s safer to grit your teeth and avoid re-using.
- If you have access to a viable alternative to relying purely on a static password (or passcode such as the ubiquitous 4-digit PIN), take advantage of it. By this I mean some form of multi-factor authentication, rather than one of the panaceas du jour that are nowadays widely publicized as a better alternative. This might sometimes be the case, but there have been too many cases where someone has assumed that one method simply replaces another. (Including some highly publicized instances where a journalist has demonstrated that people who write about security aren’t always a good source of advice.) Passwords may be obsolescent, but they’re not obsolete, and there are still (unfortunately) contexts where they’re the only game in town.
- If you’re using a service that doesn’t allow an infinite number of retries (say ‘three strikes and out’), the pressure is off a little. After all, the reason a four-digit PIN can be relatively secure is that it’s often used in a context such as locking a cellphone where retry attempts are characteristically restricted. (Note, however, that a stereotyped 4-digit passcode like 1234 dramatically increases the chances of its being guessed within three.) However, you don’t want any password that’s so obvious that it’s seriously at risk of being guessed in three (or whatever) and you certainly don’t want to make it easier to guess by using a password that might be compromised on another service (by a credentials database leak, or by an extended guessing/dictionary/brute force attack, for example).
Sadly, this is my last blog as a member of (ISC)2: my subscriptions to (ISC)2 and the BCS Institute both expire at the end of this month, and I've decided against renewing them, as I explained at length here. (Excerpt follows.)
There’s nothing sinister about this: I haven’t been drummed out ... for conduct unbefitting a computer security guru ... I’m still in sympathy with the general aims and ethics of both organizations. There are many otherwise rational people in the security business who are dismissive of any form of certification that results in an artificially lengthened signature, but I’m not one of them. These particular acronyms acknowledge many years of working to improve the security of the organizations for which I’ve worked since 1986 and the community as a whole: I’m honoured by that recognition of whatever I may have achieved in that time, and refuse to be ashamed of having been entitled to use them [the acronyms associated with my certifications with (ISC)2 and BCS].
So I wish you all a prosperous and secure future, and sign off for the last time here (or anywhere) as...
David Harley CITP FBCS CISSP
ESET Senior Research Fellow
