If they can, there’s something wrong.
Believe it or not, most online services don’t know your password. Honest.
If they can tell you your password, that’s a really, really bad thing. It calls into question their understanding of all aspects of security.
Become a Patron of Ask Leo! and go ad-free!
Services don't actually know your password
Online services don’t know your password. Instead, they use mathematical calculations called hashes to confirm the string you typed today is the same as the string you typed when you set your password. Your actual password should not be kept or stored, and services should not be able to tell you what it is. This prevents breaches from exposing actual passwords. No matter what security measures your online services use, you still need to set long, unique passwords to remain safe.
First, let’s look at why services don’t need to know your password.
There’s a mathematical concept called a one-way hash. A “hashing algorithm”, which is simply a series of mathematical calculations, transforms a string of characters (like a password) into a very large number — a “hash”. An appropriate hash algorithm has some important properties.
- It’s consistent. The hash will always return the same number for the same string.
- It’s unique. It’s extremely unlikely — so unlikely as to be pragmatically impossible — for two different strings to produce the same hash.
- It’s one-way. It’s impossible to take a hash and calculate the string used to create it.
It all sounds magical, and in many ways, it feels so. Hashes are a fundamental component of cryptography.
To be clear, this isn’t a simple formula. It’s complex, and can really only be done by a computer. But it works.
Checking your password versus knowing your password
Done correctly, an online service handles passwords like this:
- Setting a password. When you set or change your password, the service takes your new password (a string) and calculates its hash (a number). It stores the hash value in its account database and completely discards your actual password. All it knows thereafter is the hash.
- Checking a password. When you log in later and enter your password, the service calculates the hash of whatever you type. If that hash matches the hash calculated when you set the password, you must have typed the same thing both times. You typed in the correct password.
So the service only saves the hash. It never needs to keep your actual password.
Why it matters
I’m sure you’ve heard of various database breaches in the news. A hacker breaks into the servers of some service and steals their database of user accounts. If the database contains only properly-created hash values, the hacker can’t get your password. There’s no way to turn that hash value back into the string that created it: your password.
If, on the other hand, the database contains actual passwords, the hackers will have complete access to all of the accounts, including yours.
So if you encounter a service able to tell you what your password is, they’re not doing security right. And I’d be very wary of what other kinds of security-related things they might also not be doing right.
You still need strong passwords
Properly implemented hashes are fundamental to good security. But that doesn’t mean you can let your guard down. There are potential weaknesses — not in design, but in implementation — of password storage schemes. They’re all thwarted by actions you can take.
First, if a standard hashing algorithm is used, it’s the same algorithm everywhere. For example, the bcrypt algorithm (a currently-recommended algorithm) returns this for the password “password”:
Anyone, anywhere, using the password “password” on a system that uses the bcrypt hash on the unmodified2 password will have that same hash value.
Hackers know this, and have built tables (called “rainbow tables”) of all possible passwords up to a certain length (typically 8 characters) hashed using common hashing algorithms. You can’t calculate the password from a hash, but if you’ve calculated all possible hashes for all possible passwords beforehand, you can just look it up. Even tables of less than all possible passwords are useful to hackers. Tables containing hashes of the million most common passwords, for example, allow hackers to succeed a surprising amount of the time.
Your solution: make a long password that’s unique. The best would be some number of random characters. Creating a rainbow table of all possible 16 character passwords, for example, isn’t feasible. As long as your password is long and unique, you aren’t vulnerable to this possibility.
In that same vein, if two different services use the same password hashing algorithm, breaches at both might expose the fact. If you use the same password at both, they’ll find the same hash at both. If your password at one ever becomes known by other means, it’s immediately clear that it’ll work at both.
Your solution: use a different password (again, long and unique) everywhere. That way, no matter what gets exposed at any service, none of your other accounts are put at risk.
The best way to keep track of all those long, unique, random-character passwords is using a password vault. They are safe and highly recommended by security experts and random tech-advice writers like me. Here’s why.
Footnotes & References
1: While displayed and stored as a string, technically, it’s still just a very large number.
2: Good security practices by the service would modify your password with something called “salt”. This is something added to the password, unique to the service, to prevent this situation. But not using salt is still common.