Password must be at least 12 characters long, must include lower and upper case letters, must include numbers, must include special characters, must have at least 3 numbers, must have at least 2 special characters, may not include words in the dictionary. Your password is rejected because it does not comply to our policy. A policy that isn’t published anywhere, but you must make one that complies anyway. Your password has expired, make a new one that does not resemble any of the passwords that you have created in the past. And it’s all useless. We’re all doing it wrong.
So how did we get here?
Back in the early noughties (the 2000 to 2009 years for you non-British readers) there was a growing problem with security. The internet had become a common commodity and broadband internet had become affordable and was on the rise. With it came a new threat, the threat of criminal hackers increased use of the internet for infiltrating systems and stealing important data.
The NIST issued guidelines for security in this new on-line world for the United States government and, as happens often with NIST advisories, the industry at large copied and followed its advise as well. This resulted in the broad acceptance and application of the infamous 800-63 Appendix A, an advisory that not only its author, Bill Burr, regrets, but has actively begged the world to stop using. Yet not only do we continue following its advice regardless, there are people who defend it and even advocate to extend on this bad practice.
It has resulted in the world we live in today. And the sad truth of it is that it has made our world demonstrably weaker, insecure and frustrating.
So why is it wrong?
There are several articles that detail why it missed its mark, as well as an interview with the author himself admitting that he used only empirical data to come to the conclusion that formed the basis of the advisory. As the advisory itself has been discussed in detail on the internet already we’ll leave that be.
Instead of analysing the advisory, lets dive into subject matter. And as we do so, we start to see why the advised solutions are limited to ineffectual in their attempts to battle the problem, as they are not addressing the core problem.
Many of the attack vectors were already solved
To do this, let’s compare it to a public system of user names and passwords that predates the popular use of the internet, yet has remained secure with a simple four digit, never changing password: the card and PIN.
Now many will argue that the comparison is inaccurate, and you would be right to do so. The card and PIN are different factors of authentication, where the user name and password are only one factor. But there are large similarities as well, but we’ll come back to those later.
In the card and PIN system, abuse of the system has been tackled to such an extent that many of the attack vectors that are similar or identical to the ones we see in passwords are all already addressed.
Infinite retries no longer exist
The world has changed since the start of the millennium. When the original advise was made, many systems that were connected on-line were designed in an off-line world and were never susceptible to the threat of infinite tries. In those days, infinite trying required someone to try manually, hook up a physical device that would automatically try for them, or writing a piece of code that tried against a specific program or interface. All of these would require physical access, at which point countering these kinds of attacks would be all but mute.
But the on-line world has changed since then. Almost all connected, and indeed many off line systems too, have limited number of tries after which a lockout or cool down period takes effect, rapidly diminishing the success rate of these kinds of attacks. As a result, this attack vector has all but gone.
Humans don’t do complicated passwords
When confronted with password rejection, users tend to do simple substitutions on the password they tried the first time, rather than making a complex password. In addition to only slightly increasing security, by getting only small variation on simple passwords, the users tend to easily forget the password, increasing the number of password reset requests.
Each request increasing the undesired risk factor of interception, in a system where each forgotten password equates to the same mechanism as a compromised password.
We’re battling the symptoms instead of the disease
All we have been doing is battling symptoms while we should be looking at the problems of current password usage at its core. And a hint is already there in the nomer: password. We tend to forget that the password is only one of the two elements used to gain access in modern systems. Though they are both instances of the same factor, they do help as they are independent parts of the access as a whole.
We also tend to close our eyes when it comes to detectable behaviour on the server. We have rate limiting and cool downs, but we don’t do anything with the information gleaned.
So what can we do about it?
When we start looking for solutions to the problem as a whole, we can start to see the avenues we have ignored in our battles up to now.
Only when compromised or compromise is suspected
The revised NIST advisory already has this in its advise, but the first thing we should stop is changing a password. Frequent changing of passwords tend to gravitate to simpler passwords rather than more complex. Regular password changes tend to lead to the creation of passwords with only small or incremental changes between them. Ask yourself “What post fix number am I at now?” and it adequately demonstrates the problem here.
The idea behind frequent password changes for all users comes from an obsolete idea of “zero trust”, where everything, including all the users, are considered untrusted by default and trust is given by exception. This is the opposite of the card and PIN system, where every user is trusted and detected or reported abuse disables access to the system.
So, rather than requiring frequent password changes for all users, additional measures should be made to the server and its detection of suspected compromise. When too many attempts are made at a password, the account should be disabled rather than cooled down. Additionally, especially where on line services are concerned, the system should notify the legitimate holder of the detection. Include the user in the determining if the account has been compromised.
Encourage instead of demand
Many interfaces already do a variant of encouragement by displaying a strength indicator for a password field. But many still continue their practice of mandating that the password be strong before allowing submission.
This, again, comes from a misunderstanding that a system that allows for complex characters to be used in their passwords is only viable if the passwords stored in it are all complex. This is a misconception, as a simple password stored in a system that allows complex passwords, would still require hackers to consider all the possibilities of the system in guessing the password.
But that is not the only flow in thinking. By requiring complex passwords, hackers can rule out simple password, limiting instead of increasing the possible guesses as simple passwords can be ruled out completely.
By stopping the implied judgment of passwords, by calling simple passwords “weak” and complex passwords “strong”, with the added implied judgment color scale from red (considered as stop) to green (considered as go ahead), we get encourage a mix of passwords of every style in our storage. More technical users can use complex generated passwords, while others may still use simpler yet stronger than a forced complex passwords.
This can be further encouraged by scaling in a non-judgmental scale from “simple” to “complex”, with an accompanying color scale from blue to green instead.
In a mixed system like this, no shortcuts can be taken in guessing passwords as neither simple word passwords nor complex character passwords can be ruled out completely.
Change both your user name and password
If we go back to our banking example, whenever you lose your card or it gets stolen, the bank doesn’t just change your PIN and leave your lost/stolen card valid. They invalidate your card and give you a new one with a new PIN.
In a similar way, we should change our user name as well as our password. By dropping the predictable and static nature of the unchangeable user name, hackers lose the ability to try against it for more than the allowed number of attempts. Now hackers have two variable components to deal with, exponentially increasing the complexity.
This requires a huge change in a world where often e-mail addresses are used as user names. Which brings us to another part of the disease.
Stop using e-mail addresses as user names
For a great many of us, the e-mail address is as fixed as our identity. We tend to only have one and we resist changing it. It is part of what we are, when we lose access to it we lose a large part of our social circle with it. Getting everyone you know to update your e-mail contact is hard. And, yes, you can replace e-mail with FaceBook account, WhatsApp account or any other social media account, and the same rule would apply.
So in a way it is a pseudo identity factor in the tiers of security. This is a problem, because unlike a true identity factor, it is at its core a knowledge factor. And as a knowledge factor it can be duplicated, duplication is trivial, and it happens without you knowing. This is a godsend for malicious hackers because when they know your e-mail, they will know it is your user name for (virtually) ever. A huge advantage for them, as they now only have to guess your password.
There are many more possible changes that will strengthen security overall. If we, as the community at large, finally admit that focusing on the password alone was a mistake to begin with. A solution that is both friendlier to the user and better for security can be devised. After all, we have a similar system where we felt secure with an unchanged four digit password to guard all our finances for over three decades.