Password hashes need a slow cost
You do not choose a hash for the database; you choose it for the attacker who reads the database. Dedicated password hashes trade speed for resilience to increase the cost of offline guessing after a leak. Salt separates work; cost slows each guess. Verify with the stored parameters first, and consider a stronger rehash only after successful authentication. Weak passwords and server availability still set limits. Fast is the wrong goal Speed is the enemy here. General-purpose hashes such as SHA-256 are intentionally fast, allowing offline attackers to test guesses efficiently; actual rates depend on algorithm and hardware. Purpose-built password algorithms (bcrypt, scrypt, Argon2id) add a tunable cost factor plus per-user salt, so guesses require deliberate work and independently salted accounts have different stored values even with a shared password. The added per-guess work is the feature; its benefit still depends on the selected parameters and password strength. Choose an algorithm that is memory-hard where feasible, and pick a cost that stays high yet tolerable on the hardware that has to verify every login. ...