> depending on work factor

Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per thousand. This comment seems a little like saying "I can run faster than a car, depending on how hard you press the accellertor."

The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password?

Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU unfriendly due to memory allocation patterns) won't allow you to do much more than a dictionary / rule + dictionary attack, so in the short term you're only going to get weak passwords.

I don't think anyone has any expectation that a login should be as fast as any other page load. Same thing for authorising a payment. I don't think a 1 sec delay when authenticating is unreasonable.

To me the risk with using bcrypt is DOS. If you have a high work factor, all an attacker has to do is to run a lot of logon (no need to be successful, they just need to relate to real users) to sink your servers.

No matter what you do, you always need to have a rate limiter / DOS mitigation for your login APIs / pages.

> The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password?

Is there a way client side processing power could be leveraged to help calculate the final hash value so that the computational cost could be practically increased?

I'm aware that having the client calculate and send the final hash value by themselves is a bad idea though.

Then why even bother with bcrypt?

Because something with a cryptographic hash, like sha256, you can do millions (or in some cases billions) of hashes per second on the same GPU.

Password hashes, like bcrypt, PBKDF2 and scrypt, are massively slower. That doesn't mean they're uncrackable, it just means they are expensive to crack, so a strong password in a well implemented password hash will take a long time (and cost a lot of money) to crack, by which time the user has hopefully noticed and had time to change their password.

Additionally, there's a new player in town called Argon2 that attempts to solve the problems with bcrypt and scrypt. It's the most recent winner of the password hashing competition.

https://github.com/P-H-C/phc-winner-argon2

What problems with bcrypt/scrypt does argon2 solve?

bcrypt is limited to 72 characters (admittedly this is not that big a practical limitation), and scrypt is an excellent KDF, but wasn't designed as a password hash, and thus doesn't have great GPU defence. In practice, they're still both great, but that doesn't mean we should stop trying to do even better.

Argon2 looks really interesting, but it is still relatively new.

If someone isn't ready to go with Argon2 and truncating past 72 characters is an issue, Django (and possibly other implementations that I'm not aware of) overcome that by first hashing the password with SHA256 before passing it to bcrypt.

> scrypt is an excellent KDF, but wasn't designed as a password hash, and thus doesn't have great GPU defence

Last time I heard of scrypt, it was being used in Litecoin, a fork of bitcoin, because it was preventing GPU based crackers.

I don't know if it has anything to do with GPUs, I had thought it was due to memory, as referenced on the wiki page for Litecoin: "Litecoin uses scrypt in its proof-of-work algorithm, a sequential memory-hard function requiring asymptotically more memory than an algorithm which is not memory-hard."

It rate limits via IO (specifically memory IO) rather than processing power (CPU/GPU).

Ah, that's interesting enough to be worth looking into.

Yes if your password looks like: z1c4KzC*ITtt4Ka%vVDeei!aFSuEOTiDFCJ2NXc8Z7Jz then we are looking at enough time for you as a user to not care.

When you have a massive leak, it's better to have under 10 angry users about that they have been hacked (increasing at a slow pace) than most of your userbase raging at you and leaving your service.