Several companies have recently admitted to storing passwords in plain-text format. That’s like storing a password in Notepad and saving it as a .txt file. Passwords should be salted and hashed for security, so why isn’t that happening in 2019?
Why Passwords Shouldn’t Be Stored in Plain Text
When a company stores passwords in plain text, anyone with the password database—or whatever other file the passwords are stored in—can read them. If a hacker gains access to the file, they can see all the passwords.
Storing passwords in plain text is a terrible practice. Companies should be salting and hashing passwords, which is another way of saying “adding extra data to the password and then scrambling in a way that can’t be reversed.” Typically that means even if someone steals the passwords out of a database, they’re unusable. When you log in, the company can check that your password matches the stored scrambled version—but they can’t “work backward” from the database and determine your password.
So why do companies store passwords in plaintext? Unfortunately, sometimes the companies don’t take security seriously. Or they choose to compromise security in the name of convenience. In other cases, the company does everything right when storing your password. But they might add overzealous logging capabilities, which record passwords in plain text.
Several Companies Have Improperly Stored Passwords
In the case of Google, the company was adequately hashing and salting passwords for most users. But G Suite Enterprise account passwords were stored in plain text. The company said this was left-over practice from when it gave domain administrators tools to recover passwords. Had Google properly stored the passwords, that wouldn’t have been possible. Only a password reset process works for recovery when passwords are correctly stored.
When Facebook also admitted to storing passwords in plain text, it didn’t give the exact cause of the problem. But you can infer the issue from a later update:
…we discovered additional logs of Instagram passwords being stored in a readable format.
Sometimes a company will do everything right when initially storing your password. And then add new features that cause problems. Besides Facebook, Robinhood, Github, and Twitter accidentally logged plain text passwords.
Logging is useful for finding issues in apps, hardware, and even system code. But if a company doesn’t test that logging capability thoroughly, it can cause more problems than it solves.
In the case of Facebook and Robinhood, when users provided their username and password to sign in, the logging function could see and record the usernames and passwords as they were typed. It then stored those logs elsewhere. Anyone who had access to those logs had everything they need to take over an account.
On rare occasions, a company like T-Mobile Australia may disregard the importance of security, sometimes in the name of convenience. In a since-deleted Twitter exchange, a T-Mobile rep explained to a user that the company stores passwords in plain text. Storing passwords that way allowed customer service reps to see the first four letters of a password for confirmation purposes. When other Twitter users appropriately pointed out how bad it would be if somebody hacked the company servers, the rep responded:
What if this doesn’t happen because our security is amazingly good?
The company did delete those tweets and later announced that all passwords would soon be salted and hashed. But it wasn’t all that long before the company someone had breached its systems. T-Mobile said that the stolen passwords were encrypted, but that’s not as good as hashing passwords.
How Companies Should Be Storing Passwords
Salting Adds Extra Text to Your Password
Salting passwords is a straight forward concept. The process essentially adds extra text to the password you provided.
Think of it like adding numbers and letters to the end of your regular password. Instead of using “Password” for your password, you might type “Password123” (please never use either of these passwords). Salting is a similar concept: before the system hashes your password, it adds extra text to it.
So even if a hacker breaks into a database and steals user data, it will be that much harder to ascertain what the real password is. The hacker won’t know which part is salt, and which part is password.
Companies shouldn’t reuse salted data from password to password. Otherwise, it can be stolen or broken and thus made useless. Appropriately varying salted data also prevents collisions (more on that later).
Encryption Isn’t the Appropriate Option for Passwords
The next step to properly storing your password is to hash it. Hashing shouldn’t be confused with encryption.
When you encrypt data, you transform it slightly based on a key. If someone knows the key, they can change the data back. If you’ve ever played with a decoder ring that told you “A =C” then you’ve encrypted data. Knowing that “A=C,” you then can find out that message was just an Ovaltine commercial.
If a hacker breaks into a system with encrypted data and they manage to steal the encryption key as well, then your passwords may as well be plain text.
Hashing Transforms Your Password To Gibberish
Password hashing fundamentally transforms your password into a string of unintelligible text. Anyone looking at a hash would see gibberish. If you used “Password123”, hashing might change the data to “873kldk#49lkdfld#1.” A company should hash your password before storing it anywhere, that way it never has a record of your actual password.
That nature of hashing makes it a better method for storing your password than encryption. Whereas you can decrypt encrypted data, you can’t “unhash” data. So if a hacker does break into a database, they won’t find a key to unlock the hashed data.
Instead, they’ll have to do what a company does when you submit your password. Salt a password guess (if the hacker knows what salt to use), hash it, then compare it to the hash on file for a match. When you submit your password to Google or your Bank, they follow the same steps. Some companies, like Facebook, may even take extra “guesses” to account for a typo.
The main downside to hashing is, if two people have the same password, then they’ll end up with the hash. That outcome is called a collision. That’s another reason to add salt that changes from password to password. An adequately salted and hashed password won’t have any matches.
Hackers may eventually break their way through hashed data, but it’s mostly a game of testing every conceivable password and hoping for a match. The process still takes time, which gives you time to protect yourself.
What You Can Do to Safeguard Against Data Breaches
You can’t prevent companies from improperly handling your passwords. And unfortunately, it’s more common than it should be. Even when companies do properly store your password, hackers may breach the company’s systems and steal the hashed data.
Given that reality, you should never reuse passwords. Instead, you should provide a different complicated password to every service you use. That way, even if an attacker finds your password on one site, they can’t use it to log into your accounts on other websites. Complicated passwords are incredibly important because the easier your password is to guess, the sooner a hacker can break through the hashing process. By making the password more complicated, you’re buying time to minimize the damage.
Using unique passwords also minimizes that damage. At most, the hacker will gain access to one account, and you can change a single password more easily than dozens. Complicated passwords are hard to remember, so we recommend a password manager. Passwords managers generate and remember passwords for you, and you can adjust them to follow the password rules of nearly any site.
Another good option is to enable two-step authentication. That way, even if a hacker does compromise your password, you might still prevent unauthorized access to your accounts.
While you can’t stop a company from mishandling your passwords, you can minimize the fallout by properly securing your passwords and accounts.