Password Hash Generator & Verifier (bcrypt, Argon2, PBKDF2)

Hashing vs. encryption vs. salting

Hashing is a one-way transform: there's no key that turns a hash back into the original password. Encryption is two-way: whoever holds the key can recover the plaintext, which is exactly why you should never encrypt passwords for storage. Salting adds a unique random value to each password before hashing, so identical passwords produce different hashes and precomputed "rainbow table" attacks become useless.

Why not just use MD5 or SHA-256?

General-purpose hashes like MD5 and SHA-256 are built for speed, exactly the wrong property for password storage. Modern GPUs can test tens of billions of SHA-256 guesses per second against a stolen hash database. Password-hashing functions (bcrypt, Argon2id, PBKDF2) are deliberately slow and memory-hard, controlled by a tunable work factor, which makes large-scale offline guessing impractical. For how hashing differs from encoding and encryption, see encode vs. encrypt vs. hash ; for tuning guidance, see the OWASP Password Storage Cheat Sheet for the full rationale.

bcrypt vs. Argon2id vs. PBKDF2: which should I pick?

OWASP's primary recommendation is Argon2id, tuned for your hardware; bcrypt is a solid, widely supported fallback (note its 72-byte password length limit); PBKDF2 is the right choice when FIPS-140 compliance or built-in Web Crypto support matters, and is what ASP.NET Core Identity uses internally. None of these should run with a work factor low enough to hash in single-digit milliseconds. Raise the cost (bcrypt's cost, Argon2's iterations/memory/parallelism, or PBKDF2's iteration count) until hashing takes roughly 1 second on your hardware, OWASP's benchmark target for how long one hash computation should take.

What is a pepper?

A pepper is a secret value, stored outside the database (e.g. in a key vault or environment variable), mixed into the hash input in addition to the per-password salt. Unlike a salt, a pepper is shared across all passwords, so it doesn't replace salting; its purpose is that a database leak alone (without also compromising the pepper's storage) isn't enough to brute-force the hashes.

How does ASP.NET Core Identity hash passwords?

PasswordHasher<TUser> (used by UserManager<TUser>.CreateAsync and CheckPasswordAsync) stores a self-describing, base64-encoded blob: a format marker byte, the PRF, iteration count and salt length, then the salt and PBKDF2-derived subkey. The default (V3) format uses HMAC-SHA512 with 100,000 iterations, a 128-bit salt and a 256-bit subkey. This tool's "ASP.NET Core Identity" tab produces and verifies that exact format, plus the legacy V2 format (a 0x00 marker, PBKDF2-HMAC-SHA1, fixed at 1000 iterations) for backward-compatible verification:

// Default: PasswordHasherOptions.CompatibilityMode = IdentityV3
// (HMACSHA512, 100,000 iterations, 128-bit salt, 256-bit subkey)
var hasher = new PasswordHasher<ApplicationUser>();

string hashed = hasher.HashPassword(user, "correct horse battery staple");

var result = hasher.VerifyHashedPassword(user, hashed, providedPassword);
// result is Success, SuccessRehashNeeded, or Failed

// Tune iteration count via options:
builder.Services.Configure<PasswordHasherOptions>(options =>
{
    options.IterationCount = 210_000; // OWASP-style higher work factor
});

If you're integrating ASP.NET Core Identity with Duende IdentityServer as your user store, see ASP.NET Identity integration with IdentityServer .