Following on from Part One
Predicting the future is Hard. Bill Gates once apocryphally stated that “640k should be enough for everyone” (spoiler: he almost certainly never said that). One thing he definitely did say however, at an RSA Security conference in San Francisco way back in 2004, was that passwords “don’t meet the challenge for anything you really want to secure” and he predicted that the days of passwords were numbered.
So what makes a relatively good password?
We all have an established idea of what a good password looks like, let’s call this “current wisdom.” Current wisdom tells us of complexity requirements: “any three from upper case, lower case, numbers and symbols. At least eight characters in length.” We see this daily on our work computers, on websites, on many things which require authentication. So it must be sensible advice, right? Yet by those metrics, “Password1!” is a strong password.
So now what? Letter => number substitution? “Pa55w0rd1!” is fooling no-one I’m afraid, hackers have known this trick for a long time – hell, they invented it.
Current wisdom also says that our password must be changed every [arbitrary time period]. Sounds good? Except, coming up with a new secure password every three months is Hard, especially if you’re following best practice of having unique passwords for different systems. So people increment. A password like “!ManUnited23” is typical. If a hacker has this credential from a breach and it doesn’t work, what do we suppose its 24th incarnation might look like?
OK, so let’s block incremental passwords by policy and enforce a wholly different one each time. Then what happens?
The more awkward we make it for people, the more they’re going to try and bypass it. Who can remember a new, unique, complex password every couple of months, even just for one system? Many people don’t know their own phone number.
So what makes a relatively good password?
An intuitive answer is length. The longer a password is, surely the more attempts it will likely take to guess it. Let’s put some rough numbers against this. Assume a hacker has a decent cracking rig and already has a local copy of a breached database. On running a brute force attack – ie, trying every possible permutation of characters – a 6-character password will already have been cracked before you’ve read to the end of this sentence. It’ll take until tomorrow for an 8-character password; a 10-character will take 20 years. So clearly, password length is good. Right?
Except, brute-forcing is Hard. No-one would ever do this unless it were a last resort. More likely, they’d compare it against a word list. Security breaches happen all the time and a lot of that data ends up on the murkier corners of the Internet. The tireless Troy Hunt has bolted one such list, with something like 300 million breached passwords, into a web page you can play with right now. Go see if yours is in there. I’ll wait.
https://haveibeenpwned.com/Passwords
Back? Good. I have here a password list clocking in at 11GB. Assuming all passwords average 10 characters (spoiler: they don’t, if only!) then a 1kB text file will contain 100 passwords. 1MB, a hundred thousand. 1GB, a hundred million. My file then – how’s your maths? – is over one billion passwords, all real-world passwords obtained from data breaches and made (ahem, sort of) publicly available. Time to iterate through that lot on the cracking rig above? About 10ms.
So what makes a relatively good password?
What makes a relatively good password is something in addition to or instead of a password. As it turns out, Bill was right after all.
Look out for Part 3 where we consider what we can do about this.