Encrypted versus hashed passwords. What’s the difference?
As you study for the CompTIA Security+ exam, it’s important that you understand the differences between plaintext, encrypted, and hashed passwords.
It’s common to hear people first getting started in IT or cybersecurity confuse encryption and hashing. After all, they kind of look the same…They both take an input and turn it into an output that should look completely different.
However, the way that they both achieve this output is very different, and so are their use cases. Oftentimes, they’re even used in combination.
With that said, let’s take a closer look at what these terms mean, how they’re different, when they’re used, and how they work.
By the way, this article is pulled directly from one of our lessons in Cybr’s CompTIA Security+ SY0-601 Course where we provide you with all of the knowledge you need to pass your certification exam.
Plaintext
A password is in plaintext when it does not use any sort of encryption or hashing to mask what it truly is. This would be the equivalent of me emailing you my exact password. At that point, anyone intercepting our email communications would be able to read my password and then use it.
Plaintext offers absolutely no protection, which is why it should be avoided for transferring or storing any sensitive information like passwords, personally identifiable information (like social security numbers), or credit card data.
That’s when we can use encryption and hashing for password protection. Hashing will typically be used to protect passwords while in storage, and encryption will typically be used for secure data transfer and communication of that password information.
Unfortunately, it does still sometimes happen that businesses do not hash passwords before storing them in their databases. If the databases get breached, then every single one of the accounts stored will be compromised because they will be viewable in plaintext.
There’s absolutely no excuse for still storing plaintext passwords in this day and age because there are a plethora of solutions that are readily available for anyone to use. In fact, I feel like you’d have to go out of your way nowadays to store passwords in plaintext. But, oftentimes, systems still storing passwords in plaintext are legacy systems that have never been updated.
Another challenge is with transferring or using passwords. Sending password data from your user’s device to your application servers, and then to your database…that data is likely traveling through Wi-Fi and through cables. If that data is in plaintext, someone could intercept the transfer and read it.
Encrypted
So what does it mean for a password to be encrypted anyway? What makes encrypted data so much better than plaintext?
Encrypting data means taking plaintext data and translating it into an entirely different form. This different form is called ciphertext. Ciphertext can then only be decrypted by a secret key, as long as the encryption is strong enough and properly implemented.
The secret key and the encryption mechanisms depend on a few different factors, including whether you’re using Symmetric Encryption or Asymmetric Encryption.
Overall, encryption helps protect data confidentiality when it’s stored on a device, or when it’s being transmitted over the network.
Speaking of, what are the differences between symmetric and asymmetric encryption?
Symmetric Encryption
Symmetric-key encryption uses the same secret key for encrypting data as it does to decrypt the data. That makes this type of encryption a lot faster than asymmetric encryption.
A downside of this approach is that the sender and the recipient need to exchange keys, because otherwise, they won’t be able to communicate.
Sending encrypted keys itself needs to be secured, and it adds overhead to communications. This is a critical step, though, because if the secret key is compromised, then communications can be decrypted by an attacker.
To help two parties exchange private keys safely, we can use a couple of different techniques. One of those techniques relies on asymmetric encryption, also known as public-key cryptography.
Asymmetric Encryption (Public-key cryptography)
Asymmetric encryption uses a public key and a private key. The public key is used to encrypt data, while the private key is used to decrypt data.
The public key is named that way because it could be broadcasted to the entire world, and no one would be able to decrypt the data unless they also have the private key.
Here’s how it works: if you need to send an encrypted message to someone else, that person can send you their public key, which you will use to encrypt the message, and then only that person can decrypt it. And vice versa if they need to respond back — they would use your public key to encrypt the response and only you could decrypt it with your private key.
As you’re reading this information, you are using encryption. If you look in the URL bar of your browser, you’ll see the domain name, and right next to that, you’ll see a padlock icon. That padlock icon indicates that you’re communicating through HTTPS which uses encryption to protect data transferred back and forth between you and the web server.
Technically, HTTPS uses both asymmetric and symmetric. Asymmetric is used to sign data in order to exchange secret keys so that symmetric encryption can then kick in.
Most websites use HTTPS nowadays, but you should never use a website that doesn’t for any sensitive actions such as payments, account registration, or account login. If you do, and someone is snooping in on your communications with that website, they will see your data being transferred in plaintext.
Hashing
Hashing, on the other hand, is quite a bit different.
If application authentication is implemented correctly, then technically speaking, services don’t actually store your passwords in their databases. Instead, they hash your password and store the hashed value of your password.
Let’s say you have the password: MyNameIsChristophe
I go to create an account on this new website using that password. Their authentication system would grab this password, run it through a hashing algorithm, which would result in the creation of a fixed-length string of text. This is also known as a message digest or fingerprint.
Input: MyNameIsChristophe
Output: 2d71be11db2d57b5157ae19faa3e61312ab2e1576416a8cb148671a0cd87f93f
The app will then store that output value in its database.
This matters because hashes are a one-way encryption process, meaning that they can’t be reversed. If someone were to compromise an entire database that contains hashed passwords, they wouldn’t be able to decrypt the passwords. They might be able to crack the passwords, but not decrypt them.
Whereas when we’re talking about encryption, if someone has access to the private/secret key, they can decrypt the information with that key.
Encrypted versus hashed passwords
In all, what are some of the main differences between hashing and encrypting?
The purpose of encryption is to secure the confidentiality of data, while the purpose of hashing is to protect the integrity of the information.
Another difference is that hashing will generate a fixed-length value once the data is passed through a hashing function, whereas encryption will generate different length data.
Take a look at these hashing examples:
Input: MyNameIsChristophe
Output: 2d71be11db2d57b5157ae19faa3e61312ab2e1576416a8cb148671a0cd87f93f
Input: MyNameIsChristopheAndMyLastNameIsLimpalair
Output: 49f6d4140a884a12e2b6429138d9d62c1bac32fc7732dddfe0a03d3618c1a1f5
As you can see, regardless of the input’s length, the output is the same length.
Versus these encryption examples:
Input: MyNameIsChristophe
Output: IN1I6gf/H1+vYQR5CMSkRowVxqoi/aBCLe24eAwE5vo=
Input: MyNameIsChristopheAndMyLastNameIsLimpalair
Output:IN1I6gf/H1+vYQR5CMSkRuDONB8IRP4mtkSUaoxBEjz/AypIB/K0jfreCkF4B3J9
Another way to think about their differences in terms of practical uses is that you would use encryption to securely send a password or credit card information from the user’s device to your web servers for processing, and then you would use hashing to store that password or credit card information in a database.
Whenever a user goes to login, the application would work with the user’s device to encrypt the data before it gets transferred. Then, it would take the password and run it through a hashing function, and it would compare that hash with the stored hash for the same user. If the hash values match, that means the user inputted the correct password. If the hash values don’t match, then the user inputted an incorrect password.
So apps aren’t technically comparing the user’s inputted and stored passwords…they’re comparing the hash values of those passwords.
All the while, even if an attacker were able to intercept communications, all they would see is ciphertext that doesn’t mean anything at all. On top of that, even if they were able to get their hands on the hashed password value, they still wouldn’t be able to login using the user’s credentials unless they were able to crack that hashed value.
To help make cracking hashes extremely difficult, we can use something called a salt…but that’s a topic we’ll reserve for another article.
Conclusion
We’ve now talked about what plaintext is, what encryption is, and what hashing passwords means. We compared when one approach should be used over another, and how both encryption and hashing can be used together to increase security.
They both have their strengths and weaknesses, and this means they can both serve unique purposes.
Responses