maybe recommend bcrypt over argon2?

[divinity76]

quoting https://security.stackexchange.com/questions/261902/argon2-vs-sha-512-whats-better-in-my-case/261925#261925

Multiple judges for the Password Hashing Competition - that selected the Argon2 family as its winner - have since acknowledged that once you tune Argon2 to be as responsive as indicated by UX studies for interactive authentication (<=500ms), it's actually worse than bcrypt from a defense perspective (better for the attacker, worse for the defender). This is because at those tuning levels, Argon2 is less resistant to parallel attack than bcrypt is when tuned to the same responsiveness. (...) some benchmarks that one of the other PHC judges (Steve Thomas) posted to support this claim.

and quoting the blake3 README.md:

NOTE: BLAKE3 is not a password hashing algorithm, because it's designed to be fast, whereas password hashing should not be fast. If you hash passwords to store the hashes or if you derive keys from passwords, we recommend Argon2.

perhaps bcrypt is a better recommendation than Argon2? (and fwiw, which is nothing, at my job, we use bcrypt, and in 2020 i was in charge of rewriting the password subsystem.. i chose bcrypt, my main argument back then was "Argon2 is too new, has yet to pass the test of time, scrypt has serious issues, bcrypt is fine, and has passed the test of time, and is readily available.." - the main candidates were bcrypt and CRYPT_SHA256, not sure why i ignored PBKDF2 but pretty sure i ignored it, and of CRYPT_SHA256 i thought "it's so simple, i can easily wrap my head around it... but so can a GPU" )

[polarathene]

I looked into that claim in the past, I'd have to dig it up as there is a conversation on reddit with Steve IIRC requesting more info and it turned out that the weakness was theoretical GPU attack which specifically ignored the fact that while bcrypt may have decent resistance to GPU attacks (due to present hardware not having enough local memory per core), it is proven that bcrypt is weak against alternative hardware (FPGA) that is more cost effective to an attacker targeting it than equivalent cost for GPU hardware.

I could try retrieve that discussion (assuming it is still intact), the discussion ceased with some concerns I raised unanswered. While I am not a professional in the field, I believe the skepticism I had was valid, especially when the questions asked were not addressed.

I am also familiar with the linked scrypt article. IIRC yescrypt addresses that issue. I should have notes on that subject too, but my conclusion was Argon2id was the most secure choice (bcrypt has not always been safe either - OpenBSD in 2014, NodeJS in 2020).

[OneOfMany07]

I thought bcrypt was lacking in some manner of protection. Like it lacked memory hardness factors. Though I only started investigating Argon2 and others today. It might depend on the details too, with one solution being more "turnkey" or "idiot proof".

When looking at the bcrypt wikipedia page there was a note about bcrypt being more secure for expected runtimes on password hashes (< 1s), but there wasn't a citation for Argon2 being worse.

The below page seems to have some discussion and data to look though. I copied the overall opinion of OP after they talked with the original judge that made the claim.

https://www.reddit.com/r/crypto/comments/l395nj/argon2_is_weaker_than_bcrypt_for_runtimes_1000ms/

"One of the judges responded below to expand on their reasoning.

It seems that it's nothing to worry about, and was mostly about an attackers hashrate changing based on workload presented, but that appears to be somewhat misinformed as bcrypt has a higher hashrate for an attacker via FPGA (costs less than GPU).

As the parameters increase for argon2, the available memory bandwidth of the GPU begins to bottleneck the hashrate, making it more favorable than bcrypt."

[polarathene]

Like it lacked memory hardness factors.

Yes you can only increase the CPU time required while the memory (4KiB) remains the same.

That's still too low for consumer graphics cards to use (local memory per compute core, larger memory pools have increased latency) last I checked, but eventually that bottleneck is probably going to resolved.

FPGA and ASIC can be optimized for running bcrypt, with FPGA being much more flexible/affordable.

---

When looking at the bcrypt wikipedia page there was a note about bcrypt being more secure for expected runtimes on password hashes (< 1s)

Just to clarify for other readers.

It's not uncommon for a server to be weaker than the attackers hardware when it comes to performing the computation.

When you adjust the work factor to support Interactive logins (<1 sec response time), the time to compute does vary based on hardware. So it's a bit difficult to qualify where that < 1s bound would be security wise.

---

I copied the overall opinion of OP after they talked with the original judge that made the claim.

https://www.reddit.com/r/crypto/comments/l395nj/argon2_is_weaker_than_bcrypt_for_runtimes_1000ms/

:wave: Hello, you found me (kwhali) and the discussion I was referring to earlier ;)

I know it's a rather lengthy discussion, but plenty of valuable info should be there.

---

You may also want to reference OWASP which presently advises argon2id as well over bcrypt when possible:

The bcrypt password hashing function should be the second choice for password storage if Argon2id is not available or PBKDF2 is required to achieve FIPS-140 compliance.