If you happen to be one of those individuals who continues to have a pulse and intake and exhale air, you no doubt occasionally have to deal with the fact that basically every service, organization, or company out there you may use or be a part of will inevitably require you to have some form of account, and then some sort of password to protect access to that account. Almost universally in this, said institution will no doubt require you to create that password using upper and lower case letters, at least one special character, at least one number, the blood of your first born child, and then just because fuck you, that’s why, may or may not allow certain special characters like spaces or an exclamation point. On this, we can only assume because the emptiness of a space reminds them of the endless void they have in their cursed souls that no amount of tormenting their users seems to be able to fill. And then just to keep you coming crawling back on hands and knees to assert dominance because of their little-man syndrome, they may also require you to change said password on some set time table like 30, 60, or 90 days. All of this, of course, makes your account more secure…

Or so they say. In truth, they are sadistic liars who should be brought before the International Criminal Courts for their extreme crimes against humanity. Most of these policies actually make your account significantly less secure, as we’ll get into in a bit.

Luckily, while there is no such thing as a perfect solution when it comes to passwords, there is a much simpler one that resolves many of the issues and annoyances of the aforementioned common practices, whilst simultaneously making your password, from a practical standpoint, largely uncrackable.

So how did we get here? When did passwords become a thing? Why are current widespread password standards wrong? Who’s responsible and why should they burn in hell? And what’s the superior solution which could be simply implemented with only some minor policy and coding changes? Let’s dive into it, shall we?

As for the origins of passwords, something akin to passwords have seemingly been used for at least as long as humans have been recording history. For example, one of the earliest references to something like a password is mentioned in the Book of Judges, which was first written down sometime around the 6th or 7th century BC. Specifically, it states in Judges 12:

“And the Gileadites took the passages of Jordan before the Ephraimites: and it was so, that when those Ephraimites which were escaped said, Let me go over; that the men of Gilead said unto him, Art thou an Ephraimite? If he said, Nay;

Then said they unto him, Say now Shibboleth: and he said Sibboleth: for he could not frame to pronounce it right. Then they took him, and slew him at the passages of Jordan…”

Fast-forwarding a bit in history and Roman legionaries are known to have used a simple system of passphrases to discern whether a stranger was friend or foe. Second century BC Greek historian, Polybius, even describes in detail how the password system worked in terms of making sure everyone knew what the current password was:

“…from the tenth maniple of each class of infantry and cavalry, the maniple which is encamped at the lower end of the street, a man is chosen who is relieved from guard duty, and he attends every day at sunset at the tent of the tribune, and receiving from him the watchword—that is a wooden tablet with the word inscribed on it – takes his leave, and on returning to his quarters passes on the watchword and tablet before witnesses to the commander of the next maniple, who in turn passes it to the one next him. All do the same until it reaches the first maniples, those encamped near the tents of the tribunes. These latter are obliged to deliver the tablet to the tribunes before dark. So that if all those issued are returned, the tribune knows that the watchword has been given to all the maniples, and has passed through all on its way back to him. If any one of them is missing, he makes inquiry at once, as he knows by the marks from what quarter the tablet has not returned, and whoever is responsible for the stoppage meets with the punishment he merits.”

Roman historian Suetonius even mentions Caesar using a simple cipher which required the recipient to know a key, in this case the correct number of times to shift the alphabet, to decipher the message.

As for more modern times, the first known instance of a password system on an electronic computer was implemented by now retired professor of computer science at the Massachusetts Institute of Technology, Fernando Corbato. In 1961, MIT had a giant time-sharing computer called the Compatible Time-Sharing System (CTSS). Corbato would state in a 2012 interview: “The key problem [with the CTSS] was that we were setting up multiple terminals, which were to be used by multiple persons but with each person having his own private set of files. Putting a password on for each individual user as a lock seemed like a very straightforward solution.”

Something we should mention before continuing is that Corbota is hesitant to take credit for being the first to implement a computer password system. He suggests that a device built in 1960 by IBM called the Semi-Automatic Business Research Environment (Sabre), which was (and still is in an upgraded form) used for making and maintaining travel reservations, probably used passwords. However, when IBM was contacted about this, they were unsure if the system originally had any such security. And as nobody seems to have any surviving record of whether it did, Corbato is seemingly universally given credit for being the first to put such a system on an electronic computer.

Of course, an issue with these early proto-passwords is that all of them were stored in plain text despite the gaping security hole this introduces.

On that note, in 1962, a PHD student called Allan Scherr managed to get the CTSS to print off all of the computer’s passwords. Scherr notes,

“There was a way to request files to be printed offline, by submitting a punched card with the account number and file name. Late one Friday night, I submitted a request to print the password files and very early Saturday morning went to the file cabinet where printouts were placed… I could then continue my larceny of machine time.”

This “larceny” was simply getting more than the four hours of allotted daily computer time he’d been granted.

Scherr then shared the password list to obfuscate his involvement in the data breach. System admins at the time simply thought there must have been a bug in the password system somewhere and Scherr was never caught. We only know that he was responsible because he sheepishly admitted almost a half century later that it was he who did it. This little data breach made him the first known person to steal computer passwords, something the computer pioneer seems quite proud of today.

Hilariously, according to Scherr, while some people used the passwords to get more time on the machine to run simulations and the like, others decided to use them to log into the accounts of people they didn’t like just to leave insulting messages. Which just goes to show that while computers may have changed a lot in the last half century, people sure haven’t.

In any event, around 5 years later, in 1966, CTSS once again experienced a massive data breach when a random administrator accidentally mixed up the files that displayed a welcome message to each user and the master password file… This mistake saw every password stored on the machine being displayed to any user who attempted to log into CTSS. In a paper commemorating the fiftieth anniversary of CTSS engineer Tom Van Vleck fondly recalled the “Password Incident” and jokingly noted of it: “Naturally this happened at 5 PM on a Friday, and I had to spend several unplanned hours changing people’s passwords.”

As a way to get around the whole plain text password problem, Robert Morris created a one-way encryption system for UNIX which at least made it so in theory even if someone could access the password database, they wouldn’t be able to tell what any of the passwords were. Of course, with advancements in computing power and clever algorithms, even more clever encryption schemes have had to be developed… and the battle between white and black hat security experts has pretty much been waging back and forth ever since.

This has all led to Bill Gates famously stating in 2004, “[Passwords] just don’t meet the challenge for anything you really want to secure.”

Of course, the biggest security hole is generally not the algorithms and software used, but the users themselves. As famed creator of XKCD, Randall Munroe, once so poignantly put it, “Through 20 years of effort, we’ve successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess.”

On this note of training people to make bad passwords, the blame for this can be traced back to widely disseminated recommendations by the National Institute of Standards and Technology, published in the page turner that was the eight page NIST Special Publication 800-63. Appendix A, written by Bill Burr in 2003.

Among other things, Burr recommended the use of words with random characters substituted in, including requiring capital letters and numbers, and that system admins have people change their passwords regularly for maximal security…

Of these seemingly universally adopted recommendations, the now retired Burr stated in an interview with the Wall Street Journal, “Much of what I did I now regret…”

Us too Mr. Burr. Us too…

To be fair to Burr, studies concerning the human psychology aspect of passwords were largely non-existent at the time he wrote these recommendations and in theory certainly his suggestions should have made for more secure passwords from a computational perspective.

One piece of the problem with these recommendations is pointed out by the British National Cyber Security Centre (NCSC) who state, “this proliferation of password use, and increasingly complex password requirements, places an unrealistic demand on most users. Inevitably, users will devise their own coping mechanisms to cope with ‘password overload’. This includes writing down passwords, re-using the same password across different systems, or using simple and predictable password creation strategies.”

To this point, in 2013 Google performed a study on people’s passwords and noted that most people use one of the following in their password scheme: The name or birthday of a pet, family member or partner; an anniversary or other significant date; birthplace; favorite holiday; something to do with a favorite sports team; and, inexplicable, the word password…

So, bottom line, most people choose passwords that are based on information that is either easily accessible to hackers or extremely common and thus easy to guess. After all, for something like a favorite sports team, even if you included a database of the name of every sports team in the world down to your kid’s little league team name, it would be a really small database by computational standards. And while you might think that’s where the special characters come in to resolve the issue. We’re just going to stop you right there.

Software made to crack passwords not only utilizes all this knowledge Google so aptly mentioned, but even the special characters practices pretty much everyone uses. For example, while a password like the word “password” everyone knows is obscenely dumb… Or, at least, you’d think so, except as noted it’s still an insanely popularly used password. BUT, a savvy user might think they are being clever by instead modifying it slightly to P@55w0rd! And, indeed, by most password strength requirement standards, this one looks insanely strong! After all, it’s got a capital letter, not just one, not just two, but three numbers! And two special characters!

Unbreakable!

…Except, any password cracking software worth its salt accounts for the fact that pretty much everyone is going to fulfill the capitalization requirement by capitalizing the first letter, fulfill the number requirement by substituting a letter for a number that looks similar to it (ie the letter e gets made into a 3, the letter s into a 5 or a $, etc.) and, you bet your buttered balls the last character in the password, if it requires a special character, is going to be an exclamation point or the common substitution of a 1. Or if the user is cursed with an account that requires frequent changes, a 2, or a 3, or a 4, etc. Thus, while that password sure looks a lot more complicated than the original simple letters of “password”, it’s only so to a human, and likely going to take no practical extra time at all for real world password cracking software to have its illicit way with your supposedly strong password.

In all of this and many other such tricks, the people writing the software to crack passwords are generally literally experts at this sort of thing, funny enough, and use every trick in the book to cut the processing time down.

Speaking of processing time, when Mr. Burr made his recommendations in 2003, it was true that a brute force attack including all characters could be overly time consuming if it was only, quite literally, just randomly guessing every possibility. However, combining more intelligent algorithms and processing power of more modern times? Let’s just say widespread botnets, other forms of cloud computing, or even just a decent graphics card setup on a single computer, can do a pretty remarkable number of intelligent guesses in short order. For example, Stricture Consulting Group all the way back in 2012 created a mere 25 AMD Radeon HD6990 GPU cluster that could process 350 billion password guesses per second. And for reference here, they also had previously used a machine with only about 1/6th of that number of GPUs to crack the passwords of 90% of LinkedIn’s then 6.5 million users…

Thus, as Castor so sagely stated in the massively underrated film, with arguably one of the best soundtracks of all time, Tron: Legacy: “The game has changed Son of Flynn!”

And speaking of the game changing, none of this really addresses the countless other ways passwords can be cracked, and arguably the more common ways- from keyloggers, phishing, network sniffing, and countless other often more practical ways to simply harvest the password directly, instead of needing to try to acquire a database for free reign in offline brute force cracking or the like. In the end, the threat model for how passwords are commonly acquired has changed dramatically from a few decades ago, yet the password policies most companies adhere to have not really changed with the times, nor reflect the data we now have on what works and what doesn’t in the real world.

That’s not to mention that, according to Yubico’s 2019 State of Password and Authentication Security Behaviors Report, over 2/3 of people commonly share their passwords with coworkers for practical reasons- arguably a much bigger security issue that should be addressed and better systems put in place first before going all sadomasochistic on your users by requiring them to change their password every 90 days.

This all brings us to the whole requirement to change passwords at some set interval, which, according to a report by the Massachusetts tech research and analysis firm Forrester, Benchmark Your Employee Password Policies and Practices, 77% of companies require employees to change passwords every 90 days, and about 13% every 30 days.

Luckily, at least on this one- not that many companies have seemed to have noticed- the aforementioned NCSC now recommends, among other sensible tweaks to password guidelines, that system administrators stop making people change passwords unless there is a known or possible password breach as, “This imposes burdens on the user (who is likely to choose new passwords that are only minor variations of the old) and carries no real benefits…” Further noting that studies have shown that “Regular password changing harms rather than improves security…”

Or as Physicists and noted Computer Scientist Dr. Alan Woodward of the University of Surrey notes, “the more often you ask someone to change their password, the weaker the passwords they typically choose.”

Let’s not stop there, but also as Chief Technologist for the FTC Lorrie Cranor concurs on, “Unless there is reason to believe a password has been compromised or shared, requiring regular password changes may actually do more harm than good in some cases. (And even if a password has been compromised, changing the password may be ineffective, especially if other steps aren’t taken to correct security problems.)”

In essence, when a user knows they are going to need to frequently change their password, they put minimal effort into coming up with a good one, and minimal effort into changes over time, often utilizing extremely predictable patterns- things like adding an extra exclamation point at the end, or incrementing a number or the like.

Enter a study done at the University of North Carolina at Chapel Hill looking at a dataset of over 50,000 real world accounts required to be changed every 3 months over a span of a couple years. They churned away at these accounts and were able to crack at least one of the passwords used over time on 60% of the accounts using standard password cracking software. They then developed custom software to try to predict what previous and subsequent passwords for a given account would be, training it on the known subset of password transformations. The results were that in about 1 of 5 of the accounts, they could predict the changed password within a mere 5 guesses! And, further, when expanding guessed beyond 5, they could crack almost half of the accounts’ passwords throughout these changes within 3 seconds using a relatively standard powered computer- all because of human predictability in password changing patterns.

Going back to the whole “Why” of it all, it turns out the original timespan recommendations were largely based on the idea that it would take a typical computer of the era many days or even months to brute force crack a given password of a given length. And, thus, setting the time table at a given span like 30 to 90 days would be sufficiently short that the password would likely change before it could be cracked… Which obviously for reasons we’ve just explained ad nauseum is something that makes zero sense in more modern times and with sophisticated password cracking software.

And while some argue that people’s practice of re-using passwords on many accounts, some of which occasionally have data breaches, does see some benefit to some sort of requirement for a regular changing interval- ensuring that at least on your system it will be somewhat unique from the rest… Well, once again, we come back to the predictability of many changes, as well as how much burden this places on the users, and the very well studied tendency for people to make easier and easier to crack passwords the more frequently they are required to change them.

Thus, requiring frequent changes and overly complex passwords provides little real practical benefit, while also imposing extra burden on IT staffs, with one study showing about 1/3 of all IT Help desk tickets and calls are related to password resets. As an example, in another study by the aforementioned analysis firm Forrester, one university they looked at saw 8,000 password resets requested per month, almost a thousand per month of which could not be resolved without contacting the IT help desk directly. This isn’t just an issue of practical productivity loss, but also an issue of annoying the crap out of your employees and users for no good reason.

And speaking of poorly implemented password recovery systems- don’t even get us started on security questions. “What is your mother’s maiden name?” “What is your favorite color?” “What is your favorite sports team?” add virtually zero extra security benefit in the way usually implemented with questions like this that are either relatively easily looked up, or have such an extreme finite list of possible answers as to be worthless. Or, at least, we think most people aren’t answering the “What is your favorite color?” question with “celadon,” and rather something like “green”. BUT, even if you did put celadon, let’s just say the database of possible color names isn’t exactly long from a computational standpoint. This is no different than that the list of possible maiden names, sports teams, etc. isn’t terribly difficult either for a computer to churn through, even if an entity didn’t want to look your mother up for… reasons… or guess that because you’re from Washington your favorite sports team is probably the Seahawks, Mariners, Kraken, or Sounders. But we digress.

In all of this, a theme is that there is a theoretical side of good password requirement design, and then there is the real world practical side, with those two things often being at odds- demonstrating that what works in theory, can often have the opposite effect in practice because humans are going to human, and the people trying to break into accounts are really smart and know exactly how we are going to human.

So, alternate character and number requirements don’t add much extra protection in the real world, nor does regularly requiring users to change their password to one they haven’t used before, with both actually seeming to have some level of negative impact on everything. And, in all, just frustrating users and wasting IT staff time.

So what IS best here then? As in all facets of life unfortunately, length is king… I mean, girth can be handy in terms of large character sets. But, the world of internet security, much like my college girlfriend, is, sadly, more of a length size queen.

For example, a password like “My password is pretty easy to remember.” is generally going to be, quite literally, orders of magnitude more secure than “D@ught3rsN@m3!1”, and massively easier to remember. The one caveat here being because humans are going to human, any guidelines on creating such a lengthy, but simple, password are going to want to strongly recommend to users not pick things like well known song lyrics or quotes, or the same phrase they use on other accounts. Naturally, people are going to do all of this anyway, but that’s really not that different from how many people currently use things like “123456” or “password” as their password. And, sure, requiring a 25+ character completely random password utilizing every character on the keyboard would probably be a lot more secure than a 25+ character phrase in some human language. But, that’s just not going to be practical outside of someone using a password management service for all their logins.

Again, there is no such thing as a perfect system. The goal, as in all facets of life, is not to strive for perfection- that’s impossible- but, rather, to strive for the least imperfect.

And on this note of length, one report done by Discourse Research analyzing the most common passwords out there (and thus, ones that get cracked really easily because the password crackers also know they are the most common), found that a full 80% of them were 10 characters or less. Thus, you eliminate the bulk of this entire known dataset of common passwords if you just require 10 characters or more. Sure, requiring everyone to have longer passwords creates a whole new dataset of most common passwords, but it will be, by virtue of that sweet, sweet extra length, more varied.

And to illustrate the power of length over shorter girth, if using a 95 character alphanumeric set with special characters, an 8 character password means 6.634 quadrillion possibilities. In contrast, a 16 character password, even if we just use lowercase letters and no other characters, has 43.8 sextillion possibilities… Meaning, all things being equal, that will take 6.5 million times longer to crack despite being only lowercase letters and only twice the length of the password that had almost 4 times the number of possible characters.

Granted, all things aren’t equal and humans are going to human using common phrases and the like. But, again, there is no perfect system. We just want to make a better one that doesn’t result in anyone going postal on your IT staff.

…Of course, then there’s the arguably just as big of an issue- the seemingly weekly occurrence of some major service having their database breached, with said systems sometimes using weak encryption or even none at all in storing of private data and passwords. And lest you think this is an issue only in small companies of yesteryear who have no real expert IT staff… Enter Equifax who, in 2017, saw their database breached in the most face-palmy way imaginable, exposing about 145 million people in the United States’ data, including full names, Social Security Numbers, birth dates, and addresses. (Across the pond, Equifax also noted about 15 million UK citizens had their records stolen in the breach as well.)

In shades of the first ever password hack mentioned previously which required Scherr to just request that the password file be printed, it turns out to get access to the vast amount of personal data Equifax stores on people, an anonymous computer security expert told Motherboard, “All you had to do was put in a search term and get millions of results, just instantly—in cleartext, through a web app.”

Yep…

Again, there is no such thing as a perfect or unbreachable system. It does not exist and never will. But we can do better on all fronts. We have the technology. And, when it comes to password requirements, we don’t need to continue to annoy people and waste valuable IT time. So let’s fix this, shall we?

And on the user end, to get around having to endure the ridiculous requirements of our sadistic overlords while doing what you can to protect your accounts, we’d recommend a good password management app, combined with multi-factor authentication using relatively cheap USB keys. We have that technology too. And while, again, no system is perfect or unbreakable, it’s one of the closest things we currently have to the least imperfect. And certainly a lot better than most systems’ password strength checkers which think substituting a $ for an S makes your password stronger in the real world.