A team currently uses bcrypt and is evaluating a move to scrypt or Argon2id, reasoning that "they're all slow, adjustable password hashes, so it's a lateral move." What's actually different about scrypt's memory-hardness compared to bcrypt's CPU cost, and why does that distinction matter for what an attacker can practically do?

bcrypt and PBKDF2 make guessing expensive by burning CPU time — more rounds, more iterations — and that's real protection, but a CPU is the one resource an attacker can cheaply throw many of at a problem in parallel, on hardware built for exactly that (a GPU, or purpose-built ASICs for the more popular algorithms). scrypt (and Argon2id after it) adds a second resource an attacker can't get around by adding more cores: memory. scrypt fills a large buffer and reads back through it in an order that depends on data it already computed rather than a fixed, predictable order — which means the buffer has to exist, in full, for the whole computation, and every parallel guess needs its own separate buffer. A CPU or a general-purpose GPU has comparatively little fast memory per core, so running many guesses in parallel costs memory in a way that doesn't scale the way parallel CPU cycles do. I'd rather not put a specific number on exactly how much harder that makes large-scale parallel attacks in practice — it depends heavily on the chosen parameters and the attacker's hardware budget — but the mechanism itself, forcing per-guess memory rather than only per-guess time, is the real and meaningful difference from a CPU-only cost function.