From time to time, we see headlines about massive data breaches, in which millions (recently over 1 billion) sets of user credentials have been stolen by cyber criminals. Scary stuff, right?
Most people don't realize that what happens behind the scenes, the actual security practices employed by the software architects and engineers, can vary widely in their efficacy. So having your credentials stolen from a poorly managed site is a potentially much worse thing than one that does things the "right" way. There really aren't any laws, or even a widely accepted seal of approval for sites that employ best practices in this area. This fact should be even more scary than the data breach headlines, but it takes a minute or two to fully understand, and thus doesn't get much airplay.
False Sense of Security
Some sites require complex character combinations for passwords, while others don't seem to care. Have you ever wondered why some sites have very specific requirements on length, or the inclusion of special characters, and others don't? There is a general feeling that an interactive red=weak, green=good! indicator as you type means you are dealing with a firm that takes security seriously, and that you have less to fear than with sites which don't take such care.But, that's not necessarily true. Here's why.
1. If the site is actually storing the password you enter, that's bad! And there's really no way for you to know that unless they tell you.
2. Despite many, many warnings, a lot of people still use the same password for multiple sites. Maybe even for ALL business they transact on the web. For these folks, having their password stolen from one site could be a BIG problem.
If passwords were handled properly by all web developers, you could literally use the same password everywhere without fear of it being stolen by cyber-criminals breaking into this or that website's database. Yes, really. How? See "The Right Way..." below.
What about https:// and that lock icon?
Most of us know that SSL (https:) and its associated lock icon (and green bar, sometimes) are things you should look for when logging in to a website. Secure Socket Layer (SSL) provides encryption between your computer and the server it's communicating with, and it provides third-party identity verification for the website's operator. That's it - it does not have anything to do with how your credentials are stored on the other side of the connection. Don't assume everything is secure just because you see https in the URL.
The Right Way: Never Store a Password in the First Place
The right thing for the website developer to do is convert your password using a mathematical function (hash) that acts as a sort of one-way scrambler. I'm calling it a "scrambler" here, but it always yields the same result for a given string of characters. Without getting into the math, a hashed value cannot be reversed to determine your password. And what makes it really useful is that a hash function always yields the same result for a given string of text. Once set, the code running the website simply uses the same one-way scrambler every time you log in, and compares the value with what is stored for your account. If they match, you get in. And NOBODY (including people who work on that site) can know what you are using for a password.Example: "password", when run through a typical scrambling (hash) function, yields:
5f4dcc3b5aa765d61d8327deb882cf99.
There are a number of commonly used hashing functions these days. Unfortunately there are also pre-compiled lists of common words that have been already been hashed. They are called Rainbow Tables. Click the link I inserted on the hashed value above and you'll see that someone has already figured that one out.
The solution for a developer is pretty simple, just tack on some extra random stuff to the user's password before running it through the hash function, and keep that "extra stuff" secret. This is called a "salt", and thus a "salted hash".
Let's try again, using "password" plus a made-up salt value of "4d^yy8@2zqnde$3" appended on the end. We get: 061398b4d8ba7374aa11d61272360572, which doesn't show up in a Rainbow Table and cannot be reversed engineered. Use a different salt value and you get a different result. Try for yourself here, it's fun!
If you are still following along here, you see now that as long as sites all use different salt (aka secret key) values, and only store the result of the hashing function, you really could be perfectly safe using the same password everywhere without worrying when the next cyber-breach takes place.
But again, it's really up to the folks who design the software that powers a particular website as to how they choose to implement password security.
Bottom Line
Bottom Line #1: Since you don't know if the websites you use are handling passwords correctly, you really, really need to use different ones for each site.Bottom Line #2: If you manage this function in your company and don't know how this is done, you should find out immediately. Storing actual passwords is not a good practice, and should never be done unless there is some super-good reason.
