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.