You would think.
That’s what makes it so frustrating when these attacks end up being successful.
The problem is that security is often an afterthought. In fact, it’s often not thought of in any deep sense until after a successful attack.
The good news is, there’s something simple you can do about it.
Become a Patron of Ask Leo! and go ad-free!
Anatomy of a “poor” website
As discussed in that earlier article, websites do not (or, rather, should not), keep a record of your password. Instead, they “hash” the string of characters you provide as your password, and store that hash instead. When you log in, they hash the password you type in and compare the result with the hash they stored. If the hashes match, you must have typed in the correct password.
There are several standard hashing functions. For example, if we hash the password:
using the “sha256” hash, the result is:
And that’s exactly what a “poor” website might do: nothing more than a standard hash.
The problem is that anyone who hashes “password” using sha256 will get exactly the same result. There are several approaches that allow hackers to discover which hash algorithm was used and to reverse engineer many of the passwords in a stolen database.
A “good” website adds salt
Let’s say you specify a password:
but before hashing it, the website modifies it in some way. More specifically, it modifies it in a way unique to the website via a secret method. It could be as simple as adding a string to your password:
Now when that modified password is hashed using a standard hash algorithm, the result is quite different:
Each time your password is entered, before calculating the hash, the website adds this unique information — called “salt” — to what you entered. As long as no one knows the salting string (or, more commonly, the salting algorithm, which is more complex than just adding a string) there’s no way to reverse engineer a stolen database of password hashes.1
When to be concerned
Whenever there’s a report of a user-account database breach, I look for information about exactly what that database contains. I look for one of three phrases:
- Unencrypted passwords. This is horrible security because it represents no security. Hackers need do no work; the passwords are theirs for the taking. Change your password immediately.
- Unsalted password hashes. This is the “bad” website scenario: the website designers made an attempt, but a poor one. Passwords are likely to be compromised in short order. Change your password as soon as you can.
- Salted password hashes. This is the “good” scenario. When I hear this phrase or its equivalent, I worry much less. I’ll change my password, as salting can still be implemented poorly, but I won’t lose sleep if I can’t get to it right away. Hackers aren’t going to get in easily, if at all.
What you can do
Here’s the real problem: when it comes to security, there are good websites, bad websites, and horrible websites.
You have no way of knowing which is which — at least not until after a compromise.
There’s only one practical approach: assume they’re all horrible. Assume your password may someday be compromised.
In practice, that’s simply another reason for a basic rule of password security: use a different password on every site. That way, when one site gets compromised, your other accounts are not at additional risk as well.
In other words: keep doing what I hope you’re already doing.
Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.
I'll see you there!