Hashing vs Encryption: Understanding the Critical Differences
This guide explains why hashing is a one-way process unlike encryption and identifies which algorithms are suitable for password storage and data integrity.
Encryption is a process designed for retrieval. You take a piece of plaintext and a secret key to produce ciphertext. Because the goal is for an authorised recipient to read the original message, the process is reversible. If you have the correct key, you can undo the transformation and recover your data.
Hashing serves a different purpose. A hash function takes an input of any size and produces a result that is always the same length. Whether you feed it a three word sentence or the entire contents of a national library, the output remains a fixed number of bits. For instance, SHA-two hundred and fifty six always returns two hundred and fifty six bits.
The critical distinction is that hashing is a one way street. There is no key to reverse the process. You cannot take a hash and work backwards to find the original input. Instead, you use hashes to verify integrity by comparing two outputs to see if they match. If the inputs are identical, the hashes will be identical.
Broken tools
You may encounter MD5 or SHA-one in older documentation. These algorithms were once standard but are now broken regarding collision resistance. A collision occurs when two different inputs happen to produce the same hash output. While this might seem like a statistical curiosity, it is a fatal flaw for security.
If an attacker can generate a malicious file that produces the same hash as a trusted file, you have a forgery. The system sees the matching hash and assumes the file is legitimate. For this reason, you must not use these algorithms in any context where forgery is a risk. It is a rather clumsy way to secure a system, akin to using a lock that can be opened by any piece of scrap metal.
These tools are not entirely useless. They remain perfectly adequate for non-security checksums. If you are downloading a large archive and want to ensure that no packets were dropped or corrupted by a flaky network connection, MD5 provides a fast way to check the result. It identifies accidental errors with ease, even if it cannot stop a determined human adversary.
The speed trap
The most frequent error is using a fast hash for password storage. It seems intuitive to use an efficient algorithm to keep your application responsive. However, efficiency is a gift you are giving to the attacker.
A modern graphics card can calculate millions of MD5 hashes every second. If you store passwords as simple hashes, an attacker who steals your database does not need to reverse the hash. They simply guess common passwords and hash them until they find a match. This process is known as a brute force attack. When the algorithm is fast, the cost of guessing a billion passwords is negligible.
To defend against this, you must use a slow hash or a key derivation function specifically designed for passwords. These functions are intentionally computationally expensive. By forcing the server to take one hundred milliseconds to verify a password, you make the process barely noticeable for a single user. For an attacker attempting millions of guesses, that same delay makes the attack physically and financially impossible. You shift the advantage from the hardware of the attacker back to the security of your data.
Try it: Hash identifier
Sources
Every link below is checked before this page is published.