bcrypt password storage
Storing passwords with a fast hash is a design mistake, not an execution one: the same property that makes SHA-256 great for a file checksum makes it terrible for a password. bcrypt exists to flip that logic on purpose, being slow by design, and the cost factor is the dial that controls exactly how slow.
A fixed 60 characters: version, cost and salt sit embedded before the remaining 31-character hash.
This is the tool default and a common production value, balancing brute-force resistance against an acceptable login time.
8 times slower than cost 12; useful in low-login-volume systems where higher latency is an acceptable tradeoff for more resistance.
Because bcrypt generates a new random salt on each run and embeds it at the start of the hash. This is intentional: two users with the same password get different hashes, which defeats rainbow-table attacks. Verification uses the salt stored inside the hash, so it still works even though the value changes.
Because the salt is already embedded right inside the hash string, in the 22 characters right after the second `$`; when verifying a password, the function pulls that salt out of the stored hash and recomputes with it, so a single string per user is enough for authentication, with no extra table and no risk of the salt and hash getting out of sync.
It is a difference of 2¹¹, or 2048 times more iterations, since the cost is a base-2 exponent: cost 4 runs 2⁴ = 16 iterations, nearly instant but weak against brute force; cost 15 runs 2¹⁵ = 32768, secure but noticeably slower on every login attempt.
Not beyond the first 72 bytes: bcrypt has a fixed 72-byte input limit and silently ignores any character past that point when computing the hash, so a 100-character password produces the exact same hash as just its first 72 bytes, with no security gain from the excess.
Because SHA-256 was designed to be fast, the exact property that makes it ideal for a file checksum makes it vulnerable to offline brute force at scale, since a GPU can compute billions of SHA-256 attempts per second; bcrypt solves this by being deliberately slow through an adjustable cost factor, something raw SHA-256 never offered.
Each +1 in cost doubles the computation time. 10–12 is the recommended balance today; higher values protect more against brute force but make login slower.
For safety, all bcrypt computation (generation and verification) happens in your browser using WebCrypto randomness. The password and hash are never sent to any server.