Or: why password strength checkers are useless.
A lot of people work in environments where they have to change password every few months, and where there are restrictions on what passwords must look like. Here is how to deal with that, if you don’t care about security.
- Pick two strings which are complicated enough to keep the password checker happy, which I’ll call \(s_1\) and \(s_2\). Remember them.
- Also remember a two-digit count, starting from \(00\).
- The first password is \(0s_10\), the second is \(0s_20\), the third is \(0s_11\), the fourth \(0s_21\) and so on: each time you need to change passwords you swap between the two strings, and every other time you increment the count.
This gives you two hundred passwords, at the cost of remembering two strings and a two-digit count: if you have to change password every three months this will last you fifty years.
This works becaus the thing that is forcing you to change password can know two things:
- the current and new passwords, in plain;
- the hashes of all your previous passwords.
So what you need to ensure is that each password change changes enough to keep the checker happy, and that all the hashes are different. This algorithm achieves that, while also ensuring that you have to remember almost nothing. The count is wrapped around the strings just in case the checker is looking for things that look like they have trailing counts: you might need to obfuscate it in other ways if checkers get more clever1.
Of course these passwords are terribly weak: if you know one of them you know half of them, and if you know any sequential pair you know all of them. But, if you don’t care about security but merely the appearance of security, you can use tricks like this.
Counting in hex or base 36 is a good trick: the only thing that matters is to have something you can easily remember and which changes each time. ↩