Passwords handling, despite its apparently triviality, is anything but. It usually comes up in two distinct use-cases:

1. One needs to encrypt something, but only has a password to do so. This include for example password managers, disk/file/backups/… encryption.
2. One needs to authenticate users in an interactive way, like users logging on a website.

For the former, the resources budget is pretty high: having your full-disk encryption take a couple of seconds to unlock itself is not only acceptable, but expected and kind of reassuring. For the latter, things are much more constrained, and for the rest of this post, we'll focus on it.

What we're trying to do here, is to make it as hard as possible for an attacker in possession of the database of our website to bruteforce the hashes to obtain the clear-text passwords of our users. As people tend to reuse passwords or variations across services, password leaks are a valuable resource for miscreants. And even if everyone was using unique passwords, storing them hashed increases the time it takes for an attacker to compromise accounts, increasing the odds that the breach will be discovered and passwords forcibly changed before being misused.

Let's have a look at what kind of levers we have at our disposition to make the process of cracking the hashes expensive for an attacker:

1. Computational hardness: chain computations to make them hard to parallelize/distribute.
2. Memory-hardness: requiring a significant quantity of memory, forcing an attacker to get a ridiculous amount of it to bruteforce at scale.
3. Cache-hardness: making the computation move a lot of memory around or access it in fast weird/pseudo-random patterns, to eat a significant amount of bus bandwidth and force the attacker to put data outside of the CPU/GPU cache.
4. CPU-hardness: make the attacker pay a proportionally huge CPU cost in exchange of reducing the memory requirements.

For a small web application, we:

1. Can spend some CPU time computing the hash, but not too much, as users are expecting to be logged in almost instantaneously.
2. Can't afford to have a significant amount of RAM consumed every time a user authenticates.
3. Can absolutely afford to trash the caches.
4. Don't really care about CPU hardness, as we can't afford to use a lot of memory anyway.

So our main lever in our case is cache-hardness, leaving us with 3 candidates:

• Argon2: while there is a cache-hard variant (Argon2ds), it was added after the Password Hashing Competition ended, in its specification version v1.2.1, and thus isn't really implemented/used/ anywhere.
• yescrypt: too complex for small-scale deployments.
• bcrypt: only barely cache-hard, due to its use of Blowfish whose key-dependent s-boxes are taking 4k of memory, which is small compared to today's CPU/GPU L1 caches, but it's better than nothing.

Now, bcrypt has some footguns, but if you're using a proper language or a well-designed library, those will handle them for you. Of course, if you're building a serious™ project, please do reach out to your friendly neighborhood security person, as again, password handling is a hard problem.

If you'd like to learn more on the topic, I'd recommend Solar Designer's Energy-efficient bcrypt cracking and yescrypt: large-scale password hashing, as well as Niels Provos' Bcrypt at 25: A Retrospective on Password Security, the Password Hashing Competition - Survey and Benchmark, Steve Thomas' bscrypt - A Cache Hard Password Hash talk, Soatok's blog posts on the topic, and more generally, the hashcat, HashMob and John the Ripper password cracking communities.