You might be forgiven for wondering why this advice is given out – or mandated by your IT department. There is logic behind it, but I think it does more harm than good.
So-called hackers don’t actually break into systems by guessing the password, assuming the password is non-trivial. It would take too long. If you’re using “Pa$$word1” or “admin” and think it’s non-trival, you’ve got it coming. But a reasonably long string of random letters would simply take too long to guess. It’s not like they show it in the movies.
So if your password is too long to guess, why change it? Paranoia that someone might have read the post-it note on your monitor? If that’s the case then changing it every month won’t exactly help as the horse will be well clear of the stable.
There is a reason, and it’s to do with maths and the way passwords are stored. If the system holds your password in file so it can compare it with whatever you typed in then it’s a primary school programming project. In the real world that is a very bad idea, because if someone ever got into the system and was able to read the file then they’d have everyone’s passwords, leading to access to everything else. They will be using the same password for other things.
Instead any sensible system stores a hash of the password. Take the password, pass it through a hash algorithm, and end up with a string of random-looking characters and store that. Because an algorithm always produces the same output from the same input, you can take the entered password, run it through the hash and see if it matches the stored hash version. The trick is that if you only have the hashed version it’s impossible to reverse the algorithm to get the original password back.
To see how this works, let’s use a numeric password. As computer data is always numeric anyway, a string of characters is actually a number, but the number is too large to make a good example.
Our hash algorithm could be to divide the password (or passnumber?) by Pi and throw away the integer part.
123 becomes 1521160006
456 becomes 1493080998
789 becomes 1465001990
And so on…
It’s not the worlds greatest hash algorithm, but try figuring out what password 994384198 is hashed from and you’ll get my point.
So if the password is non-trival and stored as a hash, why change it every month? Why indeed! Because if you throw enough computing power at a hash and know the hashing algorithm you can always work back and find the password by brute force – that’s to say trying every possible password. You can always open a combination lock if you go through every possible combination. The key to why this doesn’t matter is “enough computing power”. If it takes the fastest computer a month to break a hash then by the time it’s been reversed you’d have changed it anyway.
In reality, of course, you’re not looking to cut things so fine – if it can’t be broken in 100,000 years then it’s reasonably safe – the odds against reversing the hash in time are greater than 1 in a million.
Unless the password can be guessed. It might take “forever” to reverse a random hash, but if it’s a word or a name or a “clever” variation on a word or a name substituting 1 for L and $ for s, adding a number on the end and capitalising the first letter then it’ll be much quicker. Safe passwords are reasonably long and completely random.
And there’s the rub. If some genius IT manager, government cyber-security agency or Microsoft tells users to change their password every 30 days they are not going to pick a new sequence of random letters. They’re going to take their old password and increment a couple of digits on the end. Once an attacker has reversed an older hashed password it becomes trivial to reverse the current one, and if users are forced into using words or something they can re-remember easily every few weeks they’re going to be quicker to break from scratch.
So what to do? Two things: make sure users have reasonably long and properly random passwords and make sure the hashes aren’t stolen. What you shouldn’t do is implement a policy where human nature will wear them down into using weak ones.
And if you’re using ssh, use a certificate login – not a password.