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)

Rho Phi
  • 123
  • 4
  • 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](https://github.com/p-h-c/phc-winner-argon2). – Polynomial Dec 14 '17 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 '17 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 '17 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 '17 at 00: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 '17 at 09:12
  • thanks to everyone for your inputs. I have to say that I accepted this as a duplicate because that answer contained a crucial specification "assume that the attacker knows your source code". which I think is the scenario in which everyone has to puts him/herself. so the idea of "hiding" how many thousands times my database has been digested and hashed is defeated immediately if I assume my source code is leaked. – Rho Phi Dec 15 '17 at 17:33

3 Answers3

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).

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
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.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • 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 '17 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 '17 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 '17 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 '17 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).

Marc
  • 4,091
  • 1
  • 17
  • 23
  • A constant salt which is combined with each password is usually called a "pepper". – Philipp Dec 14 '17 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 '17 at 17:43