Optional bcrypt password hashing backed by bcrypt_elixir, for migrating existing bcrypt user databases.

Add {:bcrypt_elixir, "~> 3.0"} to the host application's dependencies before configuring this adapter. Bcrypt is an interoperability feature, not a recommendation: list this adapter under :legacy_hashers so existing $2a$ and $2b$ hashes — and PHP crypt_blowfish $2y$ hashes, which verify by normalizing the prefix for the backend only — keep working and upgrade to the primary algorithm on the next successful login. PBKDF2 and Argon2id remain the documented primary choices.

:log_rounds (default 12, floor 10) is the cost used for new hashes and dummy work. :max_cost (default 16, ceiling 31) bounds the cost accepted from stored hashes before the backend is invoked, so a stored hash cannot request effectively unbounded work; raise it only if a legacy database legitimately holds stronger hashes. :log_rounds must not exceed :max_cost — such a configuration would mint hashes its own verifier rejects.

Trust boundary

Stored hashes are application-controlled database values, not untrusted network input. This adapter is a minimal resource preflight, defence in depth for corrupted, imported, or unexpectedly modified values: every bcrypt-family encoding is exactly 60 bytes, so the preflight checks that fixed length, reads the prefix and two-digit cost it needs for dispatch, $2y$ normalization, and the :max_cost decision, and hands everything else to bcrypt_elixir, which owns complete format parsing and cryptographic validation. Values the preflight rejects fail closed after the configured dummy work; malformed values that fit the length and cost bounds are the backend's to reject.

Bcrypt distinguishes only the first 72 bytes of a password, and the adapter declares that limit through password_byte_limit/0. A host that configures it as the primary hasher must therefore cap accepted passwords at 72 bytes. No such policy restriction is needed when bcrypt only verifies legacy hashes that already exist.