Your ID number is not a secure password
I cracked a document password in half a second. It was a national ID number. If your business protects sensitive files this way, so can anyone else — here's the maths, and the two choices you actually have.
Right, I owe you an apology. It's been a quiet summer on here. Between a house full of family, a stack of client work, and the general gravitational pull of the Peace Country in August, the writing took a back seat. I'm back.
And I want to start with a caveat, because it changes who this post is for. If you work in infosec, none of what follows will surprise you. You already know this, and you can skim it, nod, and go back to your day. This one (probably) isn't for you, other than as an instructive piece to show to business when they (try to) challenge you on your insistence on better encryption.
No, this piece is specifically for the business decision-makers. The founders, the office managers, the finance leads, the people who send and receive sensitive documents all day and have settled into a convention that seems sensible and is, in fact, utterly worthless. If that's you, stay with me, because by the end you're going to have exactly two options to choose between.
The half-second
What brought this about is that I needed to open a password-protected PDF that I had every right to open, but the password that it was supposed to be didn't work. Like so many official documents we get these days, this one was supposed to use a South African ID number as a password. Even when you emigrate from SA, you're not going to escape this.
Now the most likely cause of an ID number not working is that somebody had fat-fingered it when they set the password. Or that it was actually stored in the company's systems incorrectly, and it was off by a character or more, somewhere.
So I did what you do when you've spent time in the infosec space and have been exposed to the tools and techniques. There's a free, open-source tool called pdf2john that reads out exactly how a PDF is locked. And there's hashcat — the tool that does the actual work, the one every security professional and every attacker already has. In polite company, it's called a "password recovery" tool but, bluntly, it's a password cracker. It doesn't reverse or unlock anything clever in some magical way, it just guesses (at a ferocious rate) and checks each guess against the lock until one fits. Both of these tools took me about a minute to set up. I used pdf2john to look at how the PDF was actually encrypted, and then built two scripts to:
- generate a small list of "the number I expect, plus every plausible typo of it". This assumed the simplest kind of slip: one wrong digit somewhere. Swap a single character, and try every possibility in every position. This is a truly tiny cryptographic set of numbers, less than 250 guesses total.
- generate a wider list of numbers accounting for two mistakes. The first that two digits were incorrect, the second that there was a neighboring pair that was accidentally transposed or swapped around. This list was still only a few thousand candidates, again truly tiny for a cryptographic number set.
I also have a third option in the bag - instead of guessing how the numbers might have been mistyped, I could literally just brute-force the entire possible set of SA ID numbers. But that wasn't needed in this case, and although my first guess struck out, my second guess hit home.
Incidentally, I'm naming the tools deliberately in this post. Not to be reckless — they're famous, they're a search away, and me pretending that they're not helps nobody. The people who'd misuse them have them and use them already, but the people who need to hear this are the ones who don't know they exist. And if I was being uncharitable - and I'm feeling that way today, after this experience - I'd say that there's a subset of people who know that these tools and attacks exist, but who don't want you to know, since that might lead you to pressuring them to do Actual Security™ and not this stupid, wasteful, infuriating security theatre everyone seems to love.
Why a long number is a short password
Let me quickly explain the things that makes an ID number a terrible password, that might not be obvious from the outside.
A South African ID number is thirteen digits. Thirteen digits looks like ten trillion possibilities, when you calculate it properly. A genuinely enormous list of possibilities.
Unfortunately almost none of those ten trillion are valid ID numbers. The first six digits are a date of birth. and the next few encode a sequence and a couple of fixed fields. The very last digit isn't free at all — it's a checksum, mathematically determined by the twelve before it, so it adds nothing. Strip out everything that can't be a real ID, and you're not left with ten trillion, you're left with something under a billion.
Here's how this number set collapses, measured on my own desktop machine — a single consumer graphics card (4090), the kind a keen gamer (me) has under their desk, with hashcat doing the work. These are real numbers from a real attack, not a thought experiment.
| What the attacker assumes | Possibilities to try | Time to crack |
|---|---|---|
| It's a random 13-digit string | 10,000,000,000,000 | ~10 days |
| It's a South African ID number or a very close relative of it | ~730,000,000 | under a minute |
| It's an ID number, and they know the birthday | ~20,000 | instant |
Read the middle row again. The moment the attacker knows they're looking for an ID number — which the convention itself announces, because everyone uses it — the ten-trillion fortress collapses to under a minute. And if they know the person's birthday, which is on LinkedIn, in an email signature, on a leaked spreadsheet, anywhere — it's over before you've finished reading this sentence.
Ten days also sounds almost reassuring, but let's be clear, nobody in the real world attacks blind when the format is this predictable. Two simple guesses (and reusable scripts) on my part and I killed most of the possible values to guess. Oh, and another fun part about an ID number? It almost never changes, unless there are particular circumstances (a Home Affairs error correction, a gender change, duplicate-ID resolution, fraud/ID-theft remediation, etc). That permanence is exactly the problem: once it leaks, you can't rotate it the way you'd change a compromised password. It's tangentially why relying on biometrics for authentication also sucks — your fingerprint is a password you can never change, so the day it's copied, it's copied forever.
Canadians, don't feel smug
I live in Canada now, so let me turn the same lens on the Social Insurance Number, because it's even worse.
A SIN is nine digits. And the last one is, again, a checksum — the same one the credit-card companies use — so it's determined by the other eight. That leaves eight free digits. Do the arithmetic on the same desktop machine and brute-forcing every SIN that could possibly exist — not guessing, not knowing anything, just grinding through all of them blind — takes about a minute and a half. Knowing it's a SIN at all pulls it under ten seconds.
The South African ID at least has the decency to look imposing at thirteen digits, but a nine digit number is actually laughably bad. If your Canadian business protects files with employees' SINs (AND YOU REALLY ABSOLUTELY SHOULD NEVER BE DOING THIS, AM I CLEAR?!), you are using a password that a bored teenager could exhaust in less time than it took me to type this sentence.
The two choices
So here's where I said we'd end up. If your organisation sends or stores sensitive documents protected by someone's ID number or SIN — and a startling number do, because it feels official and they know it's a number the recipient is likely to have (oh look, another example of why it's so damn useless as a password) — you have exactly two options. Not three. Not "we'll be careful." Two.
Option one: stop using ID and SIN numbers as passwords. They are not secrets. They're printed on forms, stored in a dozen systems, shared with every employer and bank and government office the person has ever dealt with, and — as we've just seen — trivially guessable even if they weren't. A password made of a number this predictable is a locked door with the key taped next to the lock. Use a real, random passphrase, 16 characters or longer, shared through a proper channel (no, not email), and you've closed most of the gap for free.
Option two: put modern encryption on the documents. If you genuinely can't change the password habit — some workflow, some legacy system, some person who will never remember anything but their own ID — then at least make the lock itself slow to pick. Modern document encryption (typically built on a flavour of AES-256) is built to make exactly this attack uneconomically slow, even with a weak password behind it. It won't save a truly terrible password forever, but it turns "half a second" into something that actually costs an attacker real time and money. If you're still using an older encryption format, like the AES-128 this document used, your password is honestly just an irritant to the recipient. It does stuff-all for the actual security of the document, AND wastes the authorised recipients time AND still costs your business time and money to create.
Pick and implement at least one of these options. Ideally both. What you cannot do — what I'd genuinely ask you to PLEASE STOP DOING, today — is the current thing, which is neither. Because the current thing is a document that feels secure but folds in under a minute to anyone who bothers.
Although it was a relief to get into the document, the sheer horror of how easy it was made me stop and write this article. Heck, I was in that file before my coffee machine had finished warming all the way up. It literally took 0.3 seconds to run the wider script on my single consumer GPU, and the GPU didn't even have time to hit full utilisation, and you best believe even half-determined attackers are not using a single-GPU setup to break encryption. So let's please stop with this bloody stupid security theatre, and instead rely on Actual Security™ and controls, and not Hopes and Dreams™.