How Do Websites Store My Passwords?

Whenever you create an online account, all the information you enter is sent for storage in a database which is hosted on a server. Think of a table where rows represent individual accounts, and all the different columns designate the type of data (e.g., name, email address, password, etc.) In simple terms, this is how all services store your data.

When hackers break the security of the server and steal the database, you've got a data breach. What happens next is dependent on what's placed in the cells storing the passwords.

Few people realize this, but the question of how website operators and vendors store users' passwords is very important. If they're stored correctly, a data breach will result in a few spam emails which, while a nuisance, shouldn't present too much of a threat. If the passwords are not properly secured, however, a leak could result in a compromise of an account, and many more potentially dire consequences. Let's take a look at the different password storage methods and sort the wheat from the chaff.

Plaintext: It doesn’t get any worse than that

You enter your password in the field, and a character-for-character copy of it is pasted into the database. Some years ago, this wasn't such a big problem because stealing a database was something very few people could do. Now, though, with teenagers hacking into supposedly secure servers, it puts users' data in great peril. If hackers get their hands on the plaintext passwords, there's nothing to stop them from logging into people's accounts and doing all sorts of damage. They can also take the username and password combinations and organize credential stuffing attacks during which they try the same credentials on different websites. Because many people tend to reuse passwords, these attacks are worryingly effective in most cases.

In theory, website owners should be aware of the risks by now, and it's safe to say that the big online services have long abandoned plaintext password storage. Nevertheless, many, especially small and less popular websites continue to store people's passwords in clear, human-readable format. That's why we go to great length to warn you not to reuse your passwords and to be very careful who you trust your data with.

Encryption: It sounds more secure than it is

You hear the word "encryption," and you think that it sounds very advanced and secure. Well, when it comes to websites storing your password, this is not strictly the case. The encryption process will turn your plaintext password into an ineligible string of characters, and if you put that string into the password field on the website, you won't be able to log in.

The thing is, this string of characters can be turned back into the plaintext password with a special key. Companies that encrypt users' passwords often store the login credentials and encryption keys on the same server, meaning that when the hackers break in, they can make off with the encrypted login data and the keys that will help them decrypt it. And even if the keys are stored on a different server, if the crooks managed to break into one of the company's online assets, they'll likely be able to break into another.

At this point, we should point out that the way websites encrypt passwords is different from the way Cyclonis Password Manager does it. Although you still have the option of storing your encrypted vault in the cloud, the encryption keys don't go anywhere near it. Both the encryption and decryption happen on your device, and even if hackers steal your encrypted vault, they won't be able to see what's inside it.

Hashing: Not quite what we want, but we’re getting there

Again, the plaintext password is turned into a random-looking string of characters before it's placed in the database, and again, the string doesn't work if you try to log in. This time, however, the process, in theory, at least, is non-reversible. In other words, there's no key that can turn the hashed password back to plaintext. When you type your password into the login form, it is automatically hashed, and the output is compared with what's stored in the database. If there's a match, you log in successfully. That's how the authentication works. So, where's the problem, then?

The problem is that there are many hashing algorithms, and as the time goes by, some are becoming less secure than others. A while ago, for example, an algorithm called MD5 was deemed suitable, but in 2005, experts found a practical way of breaking it. In 2013, when hackers managed to steal 3 billion login credentials from Yahoo!, the email provider was still using MD5 to hash users' passwords. Incidents like these show that in some cases, even the big companies don't use secure hashing algorithms to protect users' passwords, but this is not the only worry.

Even if the algorithm is secure enough, the same password will produce the same hash. Hackers have lists of millions of common passwords, the precomputed hashes of which are placed in the so-called rainbow tables. When they see that a hash matches, they can connect it to the plaintext password. That's why security experts won't stop urging you to use strong, unique, and completely random passwords any time soon.

Hashing and Salting: The best password storage method we have (if implemented correctly)

Rainbow tables exist because many people use the same passwords. Experts and vendors can do little about that, but they can at least make sure that the same passwords don't produce the same hash. It works like this.

A pseudorandom generator creates a unique string of letters and numbers called a salt. This string is attached to the beginning or the end of the password before it's hashed. This way, two identical passwords produce completely different hashes, and the rainbow tables don't work.

There are a couple of caveats. If hackers steal the salts, the rainbow tables can be modified, and attacks can be made possible. Using a static salt (one salt for all passwords) also presents a risk. Short salts can be brute-forced, and the storage of the salts is also important. These potential attacks are rather difficult to pull off, but they are theoretically possible.

In other words, as with everything else related to online security, there's no panacea. There are good and bad password storage practices, however, which begs the following question.

How do I know if a website is storing my password correctly?

In a word, you can't, at least most of the times. When you're signing up for an account, online service providers don't specify the way in which your passwords will be stored. Even after they get hacked, some of them fail to clarify what was stolen and what the consequences could be. In fact, a lot of the data breach notifications look like they're coming off the boilerplate.

In some cases, however, you can be fairly sure that your password is not stored correctly. Here are a couple of examples:

• You're signing up for a website that imposes an upper limit on how long your password can be. The length of your password doesn't affect the length of the hash value it produces. Of course, if a password is 100 characters-long, hashing it will take a lot of time and will put too much strain on the system, so a limit should be imposed. If it stops you at 20 characters or less, however, the database is configured not to store long strings of text, which, in all likelihood means that your password will be saved in plain form.
• You sign up for a service, and you receive an email saying something along the lines of:
  "Your account was created successfully.
  Your username is: [your username in plaintext]
  Your password is: [your password in plaintext]"
  If your password is stored in hashed (and salted) format, neither the employees of the vendor nor the system that sends the automated email will be able to see (and therefore send) your plaintext password.
• You're contacting the service provider's support team, and the agent asks for your login credentials in order to make sure that it's really you. A reputable online service must have better authentication mechanisms. Even if you disregard the risks associated with employees being able to see your password, you mustn't discount the fact that if the data is visible to insiders, it will be visible to intruders as well.
• A website is asking you to verify your account by entering a portion of your password (e.g., the last three characters). Hashing a portion of a password won't produce a portion of the entire hash. It will produce a completely different hash. If you ever encounter such a scenario, you can be pretty sure that the website is storing your passwords in either encrypted or plaintext form.

Securely storing users' passwords is both a responsibility and a challenge, and the sad truth is, you can never really know if the service provider you're signing up for is up to it. What you can do is to make sure that your passwords are reasonably long, complex, and unique.