Fast executing code has been the goal of many digital product. As a programmer, we always need to be careful with the performance of our code. But is there a case where we need to slow it down?
Turns out, there are cases where we actually want the code to perform slower than it normally is. One of them are password hashing.
Storing passwords in plain texts must NEVER be an option.
That’s why you need to provide a strong password storage strategy by hashing passwords.
Hashing simply refers chopping something into small pieces, making it look like a confused mess.
But hashing alone is not sufficient to mitigate more involved attacks like rainbow tables.
To better store passwords, you need to add salt to the hashing process.
Meaning, you are adding additional random data to the input of a hashing function, making each password hash unique.
It is generally designed to be slower to prevent future threats.
Optimizing for speed isn’t the norm after all.
Slow code is sometimes better over making speed as a universally important parameter.
It creates a fingerprint of data in assessing the integrity of the data, but not confidentiality. Slow code takes arbitrary inputs and transforming them into outputs of a fixed length.
Is slow code better than fast code?
Faster calculations means faster brute-force attacks.
That’s why you need a function that is slow at hashing passwords to bring attackers almost to a halt.It is designed to be inefficient and more difficult to calculate.
The function should be adaptive in order to compensate for future faster hardware by being able to make the function run slower and slower over time.
An ideal function should integrate two processes – hashing and salting, seamlessly.
One perfect example is bcrypt.
Its name originated from b for Blowfish and crypt which is the name of the hashing function used by the UNIX password system.
This function securely hash and salt passwords. It allows building a password security platform to guard against future threats against attackers that have computing power in cracking passwords twice as fast.
The password hashing function which is also regarded as a slow algorithm reduces the number of passwords by second an attacker could hash when crafting a dictionary attack. Systems that use slow bcrypt hashes are Linux and BSD.
Why is it better?
If an attacker knows a hash, it is computationally infeasible to find any input that hashes to that given output.
More secure password storage.
With the irreversible mathematical properties of slow hashing, it becomes a phenomenal mechanism in concealing password at rest and in motion. Also it is deterministic, meaning there’s guarantee given that the same input always produces the same output in order to verify user credentials consistently.
Instead of storing the password in clear text, you hash the password and then store the username and hash pair in the database table.
According to Jeff Atwood, “hashes, when used for security, need to be slow.”
Hashing needs slow computes to prevent brute force attacks, compare to fast computes which are more feasible, in line with the rapidly evolving power of modern hardware.
A slight change equates a big impact.
Another benefit of slow hash code is that it is not easy to predict. The hash for dontpwnme3 would be much different than the hash of dontpwnme4. Also, if an input is changed slightly, the output is changed significantly. This is what we call, the “avalanche effect.”
Slow hash code is much suitable for the modern industry.
Compare to fast code that is much feasible with the rapidly evolving power of modern hardware making it much vulnerable to dictionary and brute force attacks.
One concrete example of a slow code is bcrypt. It is a password hashing function designed to be slow and to make it even slower and slower over time, seamlessly integrating to process – hashing and salting.
By way of slow code, your development project get more security when it comes to password storage, be resistant to pre-image attacks, and very hard to predict inputs and outputs.
By Tuan Nguyen