On Sun, Sep 20, 2026 at 3:49 PM Andrey Andreev <[email protected]> wrote:
> On Sat, Sep 19, 2026 at 11:00 PM Anton Smirnov <[email protected]> wrote: > >> >> My point is mostly about this part: >> >> > Argon2 for settings that are reasonable for interactive >> > authentication is worse than BCrypt >> >> Like, if there were any successful attacks on bcrypt that negate that part >> > > Yes and no. > > That part was based on a tweet from 2019, based on many unknowns > (parameters, hardware, worse by how much, etc.) very broadly saying > sub-1000ms. > > By 2023, we have slightly more clarity and comparable strenghts at just > over 500ms: https://infosec.exchange/@epixoip/110912922574721750 (note > that it looks somewhat scary because of the large memory cost, but time > cost is always 1; very different from PHP's defaults) > At that same time the bar is described as anywhere between sub40-100ms for > bcrypt and above 400-1000ms argon2, I guess with no clear winner in > between? https://infosec.exchange/@sc00bz/110228557196895869 > > In the meantime, all of this benchmark-centric talk is missing the forest > for a tree, as cracking either algorithm is practically infeasible but > vanilla bcrypt has more serious issues relevant to the average developer: > https://soatok.blog/2024/11/27/beyond-bcrypt/ > All of the "bcrypt is stronger for auth" people have their own versions of > how to solve its non-computational weaknesses too, they do recognize the > problem, but people who care mostly about benchmarks and maths will only > talk about the benchmarks and maths. :) > > This can be a very contentious subject, and I don't want to go down the > rabbit hole if the much simpler matter of dependencies would kill the > argument anyway, hence my original question. If for a moment we assume > Argon2id is better, can we rely on OpenSSL for default? > OpenSSL is an external shared library so it cannot be always enabled. I don't think we want to bundle it which is kind or requirement for always enabled extensions. If we wanted to add some strict dependecy and treat it pretty much in libc category, then it would need an RFC on its own. But even if this was changed, then we still support 1.1.1 and will support 3.0 for some time too even after we drop 1.1.1 so I think we would need to wait for much longer anyway. Kind regards, Jakub
