2

I am told that is quite easy to crack passwords when an attacker obtains a list of hashes of these passwords. This is quite easily compared to hashes of pre-computed common passwords, or brute-force compared or attacked with a dictionary based list or rainbowlist.

For this reason fast hashes as MD5 are deprecated. My question is if by applying the hash algorithm many many times one can really achieve storage of passwords that is harder to crack with all the above mentioned approaches, or is just an illusion?

It seems to me that the answer is yes, it's more secure. If I store the hash of a password that has been re-hashed N times, an attacker would have to know how many passes of hashing I did, or guess this number. Taking N large enough seems to me it would make an attack quite unfeasible, while storing the hash would be still a quick thing (imagine some tens of thousands of hash passes, it would be still matter of seconds I guess on a CPU)

Improve this question
6
  • 3
    This has been asked quite a few times, but the answer is that repeated hashing is not really the answer against modern attacks. You need a modern solution such as Argon2.
    – Polynomial
    Dec 14, 2017 at 13:57
  • @F.Hauri Not a dupe. This question is asking about using multiple iterations of the same hash function (ie slowing down the hash function), while the linked question is about using multiple different hash functions (ie security through obscurity). Not the same.
    – Mike Ounsworth
    Dec 14, 2017 at 20:52
  • "For this reason fast hashes as MD5 are deprecated." - No; precomputed tables is the reason hashes are salted. Increased computing power is the reason fast hashes are deprecated. -- A precomputed list is effective whether the hash is fast or slow. In fact, such lists are more effective for slow hashes, because you save more computations!
    – marcelm
    Dec 14, 2017 at 21:30
  • MD5 was deprecated because it was discovered to be broken, not because it was fast. There are hashes that have been discovered to be broken in theory, but never broken in practice. MD5 has been broken in practice.
    – thomasrutter
    Dec 15, 2017 at 0:22
  • @fjw MD5 is not actually broken for password hashing. What broke MD5 was a collision attack, but for password hashing the hash function must be pre-image resistant. Pre-image resistance of MD5 has not been significantly compromised, so technically MD5 is still fine as a cryptographic primitive for password hashing. -- That said, I would strongly object to its usage for passwords; there are much better hashes that can be used at no extra cost.
    – marcelm
    Dec 15, 2017 at 9:12

3 Answers 3

Reset to default
7

You are correct that an increased number of hash iterations improves security, but is certainly not a silver bullet.

As @Marc says, you should assume the attacker knows the number of iterations, so you don't get any security there. Where you do gain, is by increasing the cost of the attack. If you're using a large number of iterations of a big slow password hashing function like argon2, scrypt or the older pbkdf2, then each guess will be more expensive in terms of CPU time and electricity costs.

The attack is still feasible, but it becomes expensive, like $50,000 USD of compute time on AWS kind of expensive, so you're forcing to ask "is the value of what I can steal with this password high enough to balance out the costs of the attack?

(As @Marc also says, this answer assumes you're doing proper salting, otherwise rainbow tables can be used and the attack becomes much cheaper).

Improve this answer
5

by applying the hash algorithm many many times one can really achieve storage of passwords that is harder to crack

Yes, if done properly. Many modern password hash functions are slow because they do a fast hash calculation thousands of times.

an attacker would have to know how many passes of hashing I did

This is normally not used as a security property. Normally the number of iterations is stored along with the hash, and not kept secret.

Taking N large enough seems to me it would make an attack quite unfeasible

This is correct, because the password hash becomes slower. A typical time to take for password hashing is 100 milliseconds. This is barely noticable for users, and greatly increases the time to do a brute-force attack.

Improve this answer
4
  • 2
    It's worth being clear that hashing multiple times is on the borderline of not being considered secure today, and the repeated hashing must be done in a correct construction (e.g. PBKDF2) rather than just flat iterative hashing.
    – Polynomial
    Dec 14, 2017 at 17:44
  • @Polynomial why is hashing multiple times is on the borderline of not being considered secure today, using a good algorithm?
    – Xen2050
    Dec 14, 2017 at 20:44
  • 1
    @Xen2050 I assume Polynomial's reasoning is because the computers that crackers use are getting very powerful. Remember that making hashing slower costs the attacker more, but it also hurts the performance of the legitimate server. Remember also that attackers are running massive 25 GPU rigs for cracking, while servers have nowhere near this much CPU power. We're starting to get to the point where slowing down the hashes enough to stop attackers is starting to have noticeable performance impacts on the legitimate server.
    – Mike Ounsworth
    Dec 14, 2017 at 20:48
  • @MikeOunsworth Thanks, so it's still basically a sound idea, but you need a very long (impractical unusably long) hash time to keep it secure. I was wondering if there was some new attack/vulnerability/machine I hadn't heard of, but I have heard some places measuring computing power in acres
    – Xen2050
    Dec 14, 2017 at 21:22
1

Performing many rounds of hashing is a start but is not sufficient.

An attacker could generate a lookup table of hashes and simply see which hashes across all your stored passwords match.

The very least you want to do is combine a salt (pseudo-random generated data) with the password, then run the result through the hashing cycle. The salt should be unique for each credential stored. This means that two identical passwords will not end up with the same hash.

For the basic rules of storing passwords, please see this cheat sheet.

Oh, and assume the number of hashes is known by the attacker. Either it's somewhere in your application, or stored along-side the hash (if it's dynamic, you need to know how many cycles to apply).

Improve this answer
2
  • A constant salt which is combined with each password is usually called a "pepper".
    – Philipp
    Dec 14, 2017 at 14:01
  • 2
    Specifically, the pepper is usually stored outside of the database so that a SQL injection attack or database backup compromise still leaves the attacker without all of the information needed to start cracking the hashes.
    – Polynomial
    Dec 14, 2017 at 17:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.