Reading a bcrypt hash
$2a$11$ then 22 characters of salt and 31 of hash. 2a, 2b and 2y are versions of the same algorithm (BCrypt.Net-Next writes $2a$); 11 is the cost: 2^11 rounds. Each step up doubles the time. OWASP asks for a cost of at least 10; BCrypt.Net-Next's default is 11.
The 72-byte limit
bcrypt uses only the first 72 bytes of the password (in UTF-8). Longer passwords, or passwords of multi-byte characters, are cut there without an error: two passwords that share the first 72 bytes get the same hash. If long passphrases matter, use PBKDF2 or Argon2 instead of pre-hashing tricks.
bcrypt in .NET
.NET has no bcrypt built in. BCrypt.Net-Next is the common package: BCrypt.Net.BCrypt.HashPassword(password, workFactor: 11) and BCrypt.Net.BCrypt.Verify(password, hash). ASP.NET Core Identity uses PBKDF2 instead.
FAQ
What cost (work factor) should I use for bcrypt?
At least 10 (OWASP). Choose the highest your servers can afford per sign-in, often 11 or 12; each step doubles the time.
Why does the same password give a different bcrypt hash every time?
Each hash gets a new random salt, stored inside the hash. Verify reads the salt from the stored hash, so it still matches.
Is bcrypt still recommended?
OWASP lists it for legacy systems, after Argon2id and scrypt. It is still far better than any fast hash such as SHA-256 or MD5.
What is the difference between $2a$, $2b$ and $2y$?
They mark fixes to old implementation bugs; for normal passwords they produce the same hash, and libraries verify all three.