-4

Let's say I have a password like: password123

If I was to hash it 30 times, will it be (nearly) breach proof? I have a loop which goes through all the hashing algorithms and hashes them continuously.

Will this stop breaches(, or make it almost impossible)?

  • 1
    Which hash algorithm(s) are you using? – Joe Feb 18 '19 at 19:23
  • @Joe List of algos: https://pastebin.com/Mwb3jYd1 – Mark Adewale Feb 18 '19 at 19:25
  • @Joe fixed it :) – Mark Adewale Feb 18 '19 at 19:28
  • 1
    Those seem to be cryptographic hash functions which aren't actually intended for password storage, and putting them all together won't help much. The question linked by polynomial is probably your best solution – Joe Feb 18 '19 at 19:32
  • 2
    Hashing passwords has more to do with mitigating the effect of breeches, not stopping them. – they Feb 18 '19 at 19:34
  • 2
    It's worth noting that 30 rounds of *any* basic hash function will be insufficient regardless of which function you pick. For a hash-based KDF like PBKDF2 you'll want something more like 10k rounds at a bare minimum. – Polynomial Feb 18 '19 at 19:37
  • Even worse, you've got stuff in there like CRC32, which will drastically reduce the entropy of any password that's actually good. – AndrolGenhald Feb 18 '19 at 20:59
  • 2
    Only 30? Consider 50,000, and even that is not ideal. – forest Feb 19 '19 at 02:50

1 Answers1

9

Multiple rounds of hashing with a regular hash function (e.g. SHA256) used to be a reasonable approach, but these days it does not really provide strong resistance against modern cracking approaches such as GPUs and FPGAs/ASICs. One reason for this is the availability and low cost of commoditised hardware implementations of SHA-family hashes, largely due to the popularity of cryptocurrency mining.

What you're describing is a little like PBKDF2, which utilises a large number of rounds of a pseudorandom function (PRF) such as HMAC-SHA2. However, it is important to note that cascading hash functions (e.g. using both SHA1 and SHA256) is not particularly useful here. The goal is to force the attacker to eat up a lot of CPU time (and other restrained resources, e.g. memory bandwidth) so that cracking the hashes is infeasible. Using a lot of different hash functions doesn't help in this goal. It also makes you beholden to a lot of different implementations, which increases the likelihood that one of them has a bug, and reduces portability if you want to replicate your hash function design elsewhere. Ultimately I would avoid any situation where you need to implement any kind of cryptography - just use a premade library/function for password hashing and be done with it.

The current recommended approach is to use a function which is both CPU-hard and memory-hard, such as Argon2. Such functions are designed to somewhat level the playing field between CPU, GPU, and FPGA/ASIC attack models by introducing operations that don't optimise well across any of them.

Polynomial
  • 132,208
  • 43
  • 298
  • 379