The Math of Password Hashing Algorithms and Entropy (2019) | Hacker News Reader

The Math of Password Hashing Algorithms and Entropy (2019)

fusionauth.io

79 pointsmooreds10 comments

The way that the security industry has been solving this problem is by continuing to increase the algorithmic complexity, which in turn causes the computer to spend more time generating one-way hashes. Examples of these algorithms include BCrypt, SCrypt, PBKDF2, and others. These algorithms are specifically designed to cause the CPU/GPU of the computer to take an excessive amount of time generating a single hash.

This is true of bcrypt and PBKDF2, but not of scrypt. The design behind scrypt is to take an excessive amount of time multiplied by memory.

This does not inspire confidence in their product.

Indeed, and no mention of password dictionaries etc. Strict brute force is an upper bound, but the low hanging fruit are often very low indeed

This seems like quite a nit, since the memory requirement is largely just defending the computational complexity against hardware optimization.

Why shouldn‘t the assumption be that an attacker can be motivated enough to use purpose built hardware?

On of the key strengths of scrypt (in theory) is that it resists custom hardware by being reliant on memory. Custom chip designers can optimize purpose built compute but purpose built memory doesn't lead to as much improvement.

It also allows one to tune things to make the ratio of GPU parallelism to on-GPU memory to be sub-optimal. Making pure hardware implementations less practical isn't the only use of memory-hard work functions.

> This does not inspire confidence in their product.

Proudly using PBKDF2 in 2019 while presenting oneself as an expert on key derivation functions is the real red flag. It's time to move on. We finished the PHC in 2015, there's multiple worthy candidates that came out the other end under heavy scrutiny. It was an incredibly well run and productive meeting of minds (in my opinion at least). The alternative winners have some novel features that might appeal in certain situations but Argon came out on top and I'm intrigued in anyones reason to not be using it.

Most competitors offered up compute, time and memory parameters that can be modified as needed. The points made in this article are redundant with modern algos.

If you are still using PBKDF2 for new codebases please take a step back and do 10 mins of research, please.

> If you are still using PBKDF2 for new codebases please take a step back and do 10 mins of research, please.

Unless you offer services to the US government and so must use a NIST-approved algorithms.

Unless bcrypt and/or scrypt and/or Argon2 [1] have stamp of approval now?

[1] https://en.wikipedia.org/wiki/Password_Hashing_Competition

I once received a security audit report on a SaaS product from the vendor where the report seemed to regard encryption and hashing as equivalent, which didn't exactly fill me with confidence in the value of the report. The product was for very sensitive data as well!

As you might expect my comments were completely ignored by the decision maker!

They base their math on SHA256, which is not a hash function anyone should be using for password hashing, being cracked by bitcoin ASICs, which are completely irrelevant to hash cracking because they are incapable of doing the required math in their current form. They are ASICs, they do 1 thing and 1 thing only, and it's not crack passwords hashed with SHA256 sadly.

This fundamental problem with their argument either shows a serious lack of understanding regarding the subject of password hashing/cracking or it's simply being done because they don't expect their readers to understand it. Given the product they are pushing, I'm uncomfortable with both scenarios.

Passwords should be hashed with Bcrypt or Argon2, maybe Scrypt or PBKDF2 in some special cases. https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

Reply on news.ycombinator.com