Why should we protect the access to the password hashes? And under what conditions can this precaution be omitted?
-
If you are not protecting access to the hashes a hacker just take it and brute-force it with the right algorithm. If he got a match he got the password and it didn't even take long because it was too easy to get the hashes. I don't think you can omit this precaution.– CyberduckCommented Oct 21, 2018 at 17:51
-
@CDRohling "and it didn't even take long" [citation needed]– problemofficer - n.f. MonicaCommented Oct 23, 2018 at 5:51
-
@problemofficer I guess I don't need to quote someone. It's defenitely clear that it lasts longer if you need to get the hash and brute-force it. More than just bruteforcing the hash alone.– CyberduckCommented Oct 23, 2018 at 6:51
-
@CDRohling: It was a joke of course. Considering how astronomically long brute force attempts of secure passwords take, saying "didn't even take long" is a bit misleading. But in reality you might be correct of course.– problemofficer - n.f. MonicaCommented Oct 23, 2018 at 7:48
-
I think the simple answer is to make the attack surface as less as possible. There is no logical reason why a website provide access to any data that your users are not gonna need ( regardless the brute-force attacks on the hash functions ).– PilfilityCommented Oct 23, 2018 at 11:03
Add a comment
|
4 Answers
Safe password storage algorithms have two main features: they're one-way, and they're slow.
- Being one-way means that given the output, you cannot efficiently compute the input. Efficient means: anything faster than trying all inputs until you get a matching output.
- Being slow means that computing an output (the stored value) from the input, takes a while. Because they're one-way, you need to try inputs, and if trying an input takes ten billion calculations on your CPU, then it's going to take a while before you checked all possible passwords.
But what if your password is in the top 10 of worst passwords, like "admin" or "123456"? Then an attacker is going to guess that within a few attempts, no matter how strong your hashing algorithm is.
Therefore, people with weak passwords will always be at risk if their hash is known to an attacker. That's why we keep them secret.
When we log in to a system, we don't want to wait 5 minutes for the server to complete the password algorithm, so those algorithms are still quite fast (something like 0.1 seconds). Because computers get faster over time, we also need to increase the number of computations done, so that it still takes an attacker (with modern hardware) a long time. Or maybe we want to upgrade to a different algorithm that protects against a certain kind of ASIC or GPU cracking program. In those cases, if the old hash is known to an attacker, they can crack the user's password more easily. So additionally, keeping the hashes secret as long as possible, we also have the most up-to-date protection at the moment the hashes get hacked.
Some people include pepper in their password hashes (see this question or Wikipedia), in which case it would be perfectly safe to publish the password hashes so long as the pepper value remains a secret. But then the question is: why would you? There is usually no advantage to publishing the hashes. When the pepper value leaks, attackers can start cracking the oldest hashes you ever published. If you protect the hashes instead of posting them publicly, attackers first have to obtain both the pepper and the user database before they can start cracking anything.
Omitting this precaution (of protecting password hashes) should never be done without the user being warned of the risk. One example of this is a tripcode, where the hash gets published as proof of identity without needing a database. This is the only case that I can think of where publishing hashes of memorized secrets is a good idea. Other hashes, such as signatures of software, are of course a different topic because those do not function as passwords.
I agree all the answers written before me, but would like to answer this question briefly:
We have to protect the hashes because that's what all hackers or pentesters want to get as to crack the hashes and find the passwords through brute-forcing, dictionary attacks, and rainbow tables. If you make easy to access them to your password hashes, you will make them very happy, for sure.
If you protect the hashes you protect your weak passwords.
Over the years the recommended password hashing algorithms have changed several time as vulnerabilities, and unexpected technological advances have occurred. There's no 100% guarantee that a hash which is safe today will still be safe in 10 year.
By protecting the hashes from being accessed by an attacker you mitigate your risk of compromise in the case where a hash is captured, and it is cracked in the future.
This is also a reason why multiple organizations require passwords to be changed on a regular basis.
There's been many large attacks where password databases get dumped, and eventually cracked. Rockyou is one of the most notable ones, it's wordlist is included in all Kali instances now. Hashes simply slow down an attacker. While some people will look at the math and say "oh, it's totally safe, it would take X million years to crack this", that's not always realistic when we see new vulnerabilities and shifts in computing paradigms all the time.
-
1Changing passwords on a regular basis is not a necessary step to protect against changing technology. You can change the way passwords are hashed simply when the user next logs in - no need to make them change their password. In fact, frequent password changes are typically counter productive and are no longer considered best practices. Commented Oct 21, 2018 at 22:23
-
Sure, frequent password changes aren't good, but something like every 6 months is still generally not disruptive. It also cuts down on password reuse since users aren't using the same password for years. Changing the hashing algorithm is a good tactic, but the concern of a leaked backup with an old hash is still a risk. There's benefits to changing passwords, as long as it's not like every month.– DaisetsuCommented Oct 21, 2018 at 22:30
-
Another issue is password sharing. Despite policies meant to prevent people from sharing passwords, it happens. Changing passwords helps limit the number of people who have access to a system if a password has been shared in the past.– DaisetsuCommented Oct 21, 2018 at 22:31
-
There is growing research that even small amounts of forced password changes can be counter-productive. Worth a read: ftc.gov/news-events/blogs/techftc/2016/03/…. Commented Oct 22, 2018 at 0:49
-
1@Daisetsu I really hope you're not advocating for company to enforce changing everyone's password every 6 months. People already have trouble picking secure passwords as it is, let alone if they have to go through the process again after a few months. The level of risk, especially for people other than key figures or those who frequently type passwords in front of students or in airport terminals or something, is really not high enough to warrant this (and even if so, it's much better to have multiple factors instead).– LucCommented Oct 22, 2018 at 10:16
Added to the answers above, some weak protocols are vulnerable to "Pass the hash" attack, where all the attacker needs to login is username and the hash of the password. The attacker doesn't need to brute-force the hash. So better not to take the risk of publishing hashes.
