Do you wish to alienate your users at your organization? Then start your next meeting with this: "I'd like to talk to you today about passwords....." You will get audible groans and some people will simply stand up and walk out. I'd bet you were questioning even reading a blog post about passwords. Why? They suck. And they sucked from the very beginning. When was the beginning of passwords, and most importantly, when will they end? Hopefully it ends sooner than later, in fact I am a strong advocate for the absolute end of passwords. I plan to argue for that in this blog post. But first we must discuss some history for some context for my password-ending argument to make sense.
Of course we can go back to pre-computer days, since supposedly the Romans used the concept of a password or passphrase to identify friend from foe as they approached a checkpoint or city gate or whatnot. While there are many reasons given for the fall of the Roman Empire, I'd like to think that it was the direct result of relying on poor passwords. But to save time we'll start our password discussion with computers.
The first passwords involving were used in two different systems as near as I can tell - there was the CTSS system at MIT, and there was the SABRE ticketing system built by IBM for American Airlines. Both were up and functioning in 1960, and both started using passwords to protect the data. As passwords are unpopular, neither side is really jumping to take credit, however Fernando Corbato of MIT usually gets the credit since it was known that they were using them in 1960. My late father was one of the early programmers on SABRE and had claimed to me that they used passwords from the beginning, but this is not confirmed nor documented.
It was expensive to have one of these giant mainframe systems, and users of these systems typically would input data and have this data get handled and the output would be printed, and they would limit by department and even down to the individual user how long one could be on the computer system. So savvy users who wanted to get more done would simply run their jobs while logged in as someone else - if they were allocated 4 hours of computing time per week, they'd just use someone else's account. This got ugly, since an entire department was charged for the computer usage time. Alice in Accounting could log in as Bob from Sales and run some reports, and Sales would get billed. So passwords were introduced to prevent Alice from simply typing "B O B" and running her reports. It was a way to prevent users from stealing each other's allocated computer time.
Next, those savvy users would do things like locate and print off the plaintext password file (because of course it was plaintext) so they'd have access to all kinds of computing time. This was happening not too long after the passwords were introduced. This was in addition to simply guessing the passwords. So it was still ugly.
By the time Unix systems were invented and introduced, the password situation was replicated on them as well. The same thing - if you knew where the password file was located, you could simply look at it and have a nice list of user accounts and their passwords. Later there were things like hashing of the password so that only an encrypted version of it appeared in that password file. Encrypting a dictionary one word at a time was often enough to figure out the passwords. Programs were written to help automate this task, and password crackers were born. To make it more difficult to perform this type of attack, salting of the password made the dictionary attack take longer. Next, when it became clear that a brute force attack against the passwords would eventually work, aging of the passwords was implemented. Now think about how odd this sounds - "We know that the password hashes will eventually be brute forced, so based off of current CPU speeds of attackers, we will expire a password every X days so that the password hash will have changed before it can be brute forced." This would totally work if CPU speed never increased, but we know how well that played out.
To further lengthen the time required to crack a password, admins added additional complexities to password requirements. The longer the better. Upper and lower case letters. Numbers. Symbols like "%" or "$". Anything to make it take longer to crack. Naturally, password crackers were upgraded to include these variations.
The Internet happened. So the passwords for all of these Internet websites were in this fragile state of potential cracking. Any web programming flaw that allowed an attacker to grab copies of system files would typically target the password file. If the website was compromised in some other form or fashion, it was always the password file that was one of the items grabbed.
Three additional points are worth noting as to how it got worse. There are more, but we'll limit it to three.
First, users were encouraged to use increasingly complex passwords that were unique to each website, without fully understanding why. They were simply told that attackers could figure it out if it were too simple. They didn't get that if you used the same password everywhere, a breach on one Internet website could lead to breaches on all Internet sites where you had used that same password. If they were told about how an attacker would do this, any question they had usually involved an answer regarding hashes, password crackers, and other boring things - and the users usually zoned out and said "fine" while muttering "good god sorry I asked" under their breathe.
Second, there was and still is no standard for these passwords. Oh sure, there is the upper/lower case part, numbers and special characters/symbols bit. But some sites had (and still have) hard limits on the length of a password or they don't allow certain characters or combinations. This is frustrating for the end user, because the website where they play Sudoku online allows any odd character and has a password length limit of 128 characters, whereas their bank limits them to 16 characters and half the special ones are not allowed. I had to explain that last one to a non-technical friend once. This person was very smart, they just were not in the IT world, and they kept pointing out how illogical and ridiculous it all appeared. "My bank is more important, so they are less secure? Shouldn't they know this?"
Finally, rainbow tables pretty much ended the whole computing power required to crack a password. So all of this nonsense was in vain anyway.
The standard became password managers, where you only had to know one password to unlock your password manager, and the password manager handled all of the other passwords. Great, and those passwords are usually created with some type of massive password generator, making them impossible to remember. Then one couples it with two factor to assure maximum security.
We've had two factor authentication for quite a while. Every security pro I knows hates those RSA tokens - not because they don't work, but because they are a massive pain in the ass to implement. Yes, two factor has improved, and given the choice of no second factor vs any second factor at all, I recommend using two factor. That said, I will now say something controversial - two factor authentication is stupid. Let me explain.
An alien craft lands, and the advanced alien delegation is greeted by Earth scientists, who wish to show off our technological advances, including the computer. The delegation observes the scientist logging in to show them Google Earth or some other science-y shit, and the following discussion takes place.
ALIEN: "What did you type in on that computer?"
SCIENTIST: "My user name and password, a security measure to protect the system from abuse. I identified myself to the computer system."
ALIEN: "So why did you have to look at your phone and do more typing?"
SCIENTIST: "Oh that's because I needed extra security because the first security measure was too weak. The phone is a second factor to determine I am who I say I am."
ALIEN: "You are using a security measure that is so broken you have to add a second security measure. What if someone has your phone? Isn't that also insecure?"
SCIENTIST: "Oh no we added a biometric detection system to the phone to uniquely identify the phone owner."
ALIEN: "Why not just use that biometric detection system on the computer?"
SCIENTIST: "Some systems are accessed remotely, so we can't do it everywhere."
ALIEN: "Do you not have a way for systems to talk to each other securely?"
SCIENTIST: "Well yes, sort of, but we argue a lot about standards and implementation." (an argument breaks out among the scientists about the standards)
ALIEN: (to other aliens) "Mostly harmless."
ALIEN: (to humans) "We've read your philosophy. We feel we finally understand your greatest philosopher, Douglas Adams. We're leaving, and as soon as you show signs of actual logic, we'll return. See you in about a million years!"
Given the choice of using two factor or not, I'd say use two factor. The whole point of 2FA is to fix the password, but it is time to eliminate it. Most of us use password managers that keep all of our passwords in one secure place, and do not know our own passwords at all anyway, so let's get rid of them.
Instead of something you know (password) and something you have (U2F token or phone), let's make two factor something you have and something you are. The second factor should be biometric, like a fingerprint, eye scan, facial recognition, or some other type of biometric identifier we haven't started using yet. If we as a people have things like dongles attached to car keys so we can find them when we inevitably lose them, then we shouldn't be relying on our knowledge of "something you know" to gain access to our bank account. Kill the password, we can still do two factor, and we can secure access to our systems.