Password Security

Password storage is designed around an assumption that sounds pessimistic and is only realistic: one day, someone may read your employee table.

It does not take a break-in. A backup restored onto a laptop, an over-permissioned reporting account, a misconfigured storage bucket, a developer copy of production data. Your database is rarely the only copy of itself.

So the question is not whether the table can be read. It is what the reader can do with it. Everything in this lesson exists to make turning stored credentials into working logins expensive, per account, including the accounts with unremarkable passwords.

SHA-256 is a good hash function. It is fast, and speed is the point of it: you want to checksum a large file or verify a download without waiting around. Hardware built for hashing computes an enormous number of them per second.

Now count the hashes each side needs. Verifying one login needs one. Working through a large list of candidate passwords against a stolen table needs billions. Speed buys you almost nothing and buys the other party everything, so choosing a fast hash optimises for the wrong party. That is the entire argument, and it does not depend on any weakness in SHA-256 itself.

A password hashing function inverts the economics on purpose. It is deliberately slow, and the slowness is tunable through a work factor — an iteration count, a memory cost, or both. Set it so one verification takes a fraction of a second on your own servers. Nobody notices that during login, and the same cost multiplies across every guess anybody makes against the stored values.

The trade-off is real and lands on you. That cost is CPU and, for Argon2 and scrypt, memory, on your own machines, on a login endpoint that may face a burst of traffic. Tune the work factor against your hardware and measure the result rather than copying a figure from an article, and re-measure when you change instance size. A setting chosen two years ago on different hardware is not the setting you would choose today.

Each password also needs its own random salt — a value mixed in before hashing so that two people who chose the same password do not end up with the same stored hash. You will rarely handle it yourself. bcrypt, Argon2 and the ASP.NET Core implementation all generate a salt per password and store it inside the string they hand back. Writing your own salt handling is a chance to get it wrong in exchange for nothing.

using Microsoft.AspNetCore.Identity;

public sealed class EmployeeAccountService
{
    // Generates a random salt per password, and records the algorithm,
    // its parameters and the salt inside the string it returns.
    private readonly PasswordHasher<Employee> _hasher = new();
    private readonly IEmployeeRepository _employees;

    public EmployeeAccountService(IEmployeeRepository employees) => _employees = employees;

    public async Task RegisterAsync(Employee employee, string password, CancellationToken ct)
    {
        employee.PasswordHash = _hasher.HashPassword(employee, password);
        await _employees.AddAsync(employee, ct);
    }

    public async Task<bool> SignInAsync(string email, string password, CancellationToken ct)
    {
        var employee = await _employees.FindByEmailAsync(email, ct);
        if (employee is null)
        {
            return false;
        }

        var result = _hasher.VerifyHashedPassword(
            employee, employee.PasswordHash, password);

        if (result == PasswordVerificationResult.SuccessRehashNeeded)
        {
            // Correct password, stored with older parameters. Upgrade it now:
            // this request is the only time the plaintext is available.
            employee.PasswordHash = _hasher.HashPassword(employee, password);
            await _employees.UpdateAsync(employee, ct);
        }

        return result != PasswordVerificationResult.Failed;
    }
}

• HashPassword returns a single string containing a format marker, the parameters, the salt and the derived hash. Store it in one column. There is no separate salt column to design, migrate or accidentally share.
• VerifyHashedPassword reads the parameters back out of the stored string, which is why a hash written by an older version of the library still verifies after an upgrade.
• SuccessRehashNeeded means the password was right but was stored with weaker settings than the current ones. Rehashing here is the only opportunity you get, because the plaintext exists in memory during this request and nowhere else.
• Both failure paths return the same false, so the response does not confirm which email addresses have accounts. Keep the message the client sees identical too — 'those details did not match' rather than 'no such user'.
• One gap worth knowing about: the unknown-email path returns without hashing anything, so it answers measurably faster than a wrong password does. If that difference matters for your application, verify the supplied password against a fixed dummy hash before returning, so both paths cost the same.
• PasswordHasher uses PBKDF2 with HMAC-SHA512 and a per-password salt by default, with an iteration count that has been raised across .NET releases. Check the current default for the version you are on, and set IterationCount through PasswordHasherOptions if you want to control it yourself. A dedicated bcrypt or Argon2 library is an equally reasonable choice; the important thing is that it is one of these four families and not a hash you assembled.