Introduction

When developers ask for a .NET implementation of bcrypt, they usually need a safe way to store passwords, not a general encryption tool. That distinction matters because bcrypt is a password hashing algorithm, not reversible encryption. In .NET, the common approach is to use a maintained library such as BCrypt.Net-Next and wrap it behind a small service so hashing and verification stay consistent across the application.

Why bcrypt Is a Good Fit for Passwords

bcrypt is designed to be deliberately slow compared with normal hash functions such as SHA-256. That slowness is the feature. It makes brute-force guessing more expensive, and it embeds a salt directly into the resulting hash so identical passwords do not produce identical stored values.

The main pieces to understand are:

• the password itself
• a random salt generated by the library
• the work factor, often called cost

A higher cost means stronger resistance to guessing attacks, but also more CPU time per login or password reset. The right value depends on your hardware and traffic profile.

Installing and Using bcrypt in .NET

A widely used library is BCrypt.Net-Next. Install it with the .NET CLI:

dotnet add package BCrypt.Net-Next

Then create a small service that hashes new passwords and verifies login attempts.

1using BCrypt.Net;
2
3public sealed class PasswordService
4{
5    private const int WorkFactor = 12;
6
7    public string HashPassword(string password)
8    {
9        if (string.IsNullOrWhiteSpace(password))
10        {
11            throw new ArgumentException("Password must not be empty.", nameof(password));
12        }
13
14        return BCrypt.Net.BCrypt.HashPassword(password, workFactor: WorkFactor);
15    }
16
17    public bool VerifyPassword(string password, string passwordHash)
18    {
19        if (string.IsNullOrWhiteSpace(password) || string.IsNullOrWhiteSpace(passwordHash))
20        {
21            return false;
22        }
23
24        return BCrypt.Net.BCrypt.Verify(password, passwordHash);
25    }
26}

This is the core workflow. When a user registers, store the output of HashPassword. When the user signs in, read the saved hash from the database and pass it to VerifyPassword.

Example Usage in an Application Flow

A service method is easy to plug into ASP.NET Core or any other .NET application.

1var passwordService = new PasswordService();
2
3string storedHash = passwordService.HashPassword("MyStrongPassword123");
4Console.WriteLine(storedHash);
5
6bool ok = passwordService.VerifyPassword("MyStrongPassword123", storedHash);
7bool bad = passwordService.VerifyPassword("wrong-password", storedHash);
8
9Console.WriteLine($"correct password: {ok}");
10Console.WriteLine($"wrong password: {bad}");

The stored hash contains the salt and cost information, so you do not need separate columns for those values unless your security design requires them for auditing.

Rehash When Your Cost Factor Changes

A useful production pattern is to increase the work factor over time. Hardware improves, so a cost value that was strong a few years ago may become too cheap. bcrypt libraries usually provide a way to detect whether a stored hash should be upgraded.

1using BCrypt.Net;
2
3public string VerifyAndUpgrade(string password, string currentHash)
4{
5    if (!BCrypt.Net.BCrypt.Verify(password, currentHash))
6    {
7        throw new UnauthorizedAccessException("Invalid credentials.");
8    }
9
10    if (BCrypt.Net.BCrypt.PasswordNeedsRehash(currentHash, workFactor: 12))
11    {
12        return BCrypt.Net.BCrypt.HashPassword(password, workFactor: 12);
13    }
14
15    return currentHash;
16}

This lets you migrate users gradually during normal sign-in instead of forcing a password reset campaign.

bcrypt Is Not Encryption

The title of many articles mixes hashing and encryption, but they solve different problems. Encryption is reversible when you have the key. Password storage should not be reversible at all. If an attacker steals your database, you want them to face a slow verification function, not a decryptable secret store.

That is why plain hashes, reversible encryption, and home-grown salting schemes are poor substitutes. bcrypt exists to solve a very specific password problem, and it is best used for that problem only.

Common Pitfalls

A common mistake is hashing passwords with a fast algorithm such as SHA-256 and assuming that a salt makes it good enough. Salting is necessary, but fast hashes are still too cheap for attackers to test at scale.

Another mistake is choosing a cost factor once and never revisiting it. Benchmark the login path on your production hardware and set a cost that is acceptably slow for your workload. Re-evaluate it periodically.

Developers also sometimes log the raw password during debugging or keep it in memory longer than necessary. Even with bcrypt in place, careless handling before hashing can still expose secrets.

Finally, do not compare stored password hashes with manual string logic. Always call the library's verify function so the check uses the embedded salt and cost correctly.

Summary

• bcrypt is for password hashing, not reversible encryption.
• In .NET, BCrypt.Net-Next is a practical way to hash and verify passwords.
• Store the bcrypt hash, not the plain password and not a separate manual salt.
• Pick a work factor that matches your hardware and raise it over time.
• Use library verification and optional rehash-on-login instead of custom comparison logic.