The History of Passwords: From MIT's CTSS to Modern Hashing

Passwords are older than the internet, older than personal computers and, in digital form, almost as old as time-sharing itself. They have been criticised for decades, yet they are still the main way we prove who we are online. Their history explains why the advice on choosing and storing them has changed so much.

Passwords for a shared machine

In the early 1960s, researchers at the Massachusetts Institute of Technology built the Compatible Time-Sharing System, known as CTSS, which let several people use a single computer at once from separate terminals. Fernando Corbató led the project. Time-sharing created a new problem: how to keep each user's files private from the others. The solution was a password for each account, and CTSS is generally regarded as one of the first systems to use them.

The earliest implementations were simple. Passwords were stored in a file in plain text. That file was protected only by the system's access rules, which meant that anyone who could read it would have everyone's password.

Later accounts describe incidents that showed the weakness. In one, a researcher is said to have found a way to print the password file in order to use extra computing time that belonged to others. In another, reported to have taken place in 1966, a software error caused the password file to be displayed to users as the daily login message. Details differ between accounts, but the lesson was clear: a file of readable passwords is a disaster waiting for a mistake.

Storing a fingerprint, not the secret

The solution was to store not the password but a one-way transformation of it, called a hash. When you log in, the system hashes what you typed and compares the result with the stored value. If an attacker steals the file, they find only hashes, and cannot simply read the passwords. The Multics system and then Unix adopted this idea in the 1970s. By the end of the decade, Unix used a modified version of the DES cipher to produce the hash, in a function called crypt.

In 1979, Robert Morris and Ken Thompson of Bell Labs published a paper, "Password Security: A Case History", describing what they had learned. They introduced the salt, a small random value combined with each password before hashing. Salting means that two users with the same password have different hashes, and it makes it much harder to attack many accounts at once with precomputed tables.

Guessing

As soon as passwords were hashed, attackers moved to guessing. They hashed a list of likely passwords and compared the results with the stolen file. The Morris worm of 1988 included its own short list of common choices, and it succeeded on many machines. As computers grew faster, brute-force guessing grew easier. Specialised hardware, including graphics cards, can now test billions of guesses per second against fast hash functions.

That is why modern systems use deliberately slow hash functions designed for passwords. The bcrypt function, introduced in 1999 by Niels Provos and David Mazières, includes a cost setting that can be raised as computers improve. Later designs such as scrypt and Argon2 add memory requirements to make hardware attacks more expensive.

The rules that did not work

For many years, advice on passwords demanded complexity: a mix of upper and lower case, digits and symbols, and a change every few months. In 2003, the US National Institute of Standards and Technology published guidance written by an official named Bill Burr that recommended such rules. Burr later said publicly that he regretted much of it. Users responded to the rules in predictable ways, choosing patterns like a capital letter at the start and a number at the end, and changing Password1 to Password2.

In 2017, NIST published new guidance, SP 800-63B, that reversed the advice. It recommended allowing long passphrases, dropping arbitrary composition rules, not forcing regular changes unless there is evidence of compromise, and checking new passwords against lists of known breached ones.

What matters now

• Length is more useful than complexity.
• Uniqueness matters most: one breach should not unlock your other accounts.
• A password manager makes unique passwords practical.
• A second factor greatly reduces the damage of a stolen password.

Another development deserves mention: the idea of a second factor. Hardware tokens that generate a changing code appeared in the 1980s, and phone-based codes and authenticator apps are now common. The principle is that something you know (a password) is combined with something you have (a device), so that a stolen password alone is not enough.

Beyond passwords

Newer technologies, such as passkeys based on public key cryptography, aim to replace passwords with something that cannot be phished or reused. They are spreading, but passwords will remain in use for a long time, so getting them right still matters.

The lesson for site owners today

Two sides of the problem affect you: how your users' passwords are stored, and how yours are handled. If you run a CMS or a shop, make sure it uses modern hashing, which established platforms do by default, and never write your own scheme. Do not store passwords in plain text, and do not email them. For your own accounts, treat the hosting, domain and email logins as the keys to your business.

1. Use a password manager and a unique passphrase for each account.
2. Turn on two-step verification wherever it is offered.
3. Change a password immediately if a service you use reports a breach.
4. Limit login attempts on your site's login pages.

If your site runs on WordPress, WordPress hosting is built around keeping it updated.

Locking things down

Strong credentials protect everything else. Our security page describes how we approach account protection, the WordPress hosting plans are a good base for a site with many users, and the knowledgebase has guides on managing logins in Plesk.