Hash Generator Password: Why General Hashes Are the Wrong Tool

The speed problem

SHA-256 is designed to hash gigabytes quickly. A consumer GPU computes billions of SHA-256 hashes per second, so an attacker holding your database works through common passwords in minutes — salt or no salt.

Password hashes invert that goal deliberately. bcrypt, scrypt and Argon2 have a tunable work factor, so a single verification takes ~100ms on your server and an attacker gets a few thousand guesses per second instead of billions.

Which algorithm

Argon2id is the current recommendation — memory-hard, so GPUs and ASICs lose most of their advantage. Tune memory first (64 MB upward), then iterations.

bcrypt remains a perfectly acceptable choice: mature, available everywhere, work factor 12 or higher today. Its one quirk is a 72-byte input limit, which matters if you accept long passphrases — pre-hash with SHA-256 in that case.

scrypt sits between them. PBKDF2 is the weakest of the four and mainly appears where a standard requires it.

What the implementation looks like

Use the library function and let it manage salt, work factor and encoding. Hand-rolled salting is where implementations usually go wrong:

// PHP — algorithm and salt handled for you
$hash = password_hash($password, PASSWORD_ARGON2ID);
password_verify($password, $hash);           // true / false
password_needs_rehash($hash, PASSWORD_ARGON2ID); // upgrade on login

The stored string carries the algorithm, work factor and salt, so raising the work factor later does not break existing users — rehash on their next successful login.

What not to do

Do not hash passwords in the browser and treat the result as the password — it just becomes the credential. Do not use a general hash generator, including this site, to produce values you store as passwords.

Do not impose a maximum password length below 64 characters, and do not strip characters. Both reduce entropy for no security benefit.