bcrypt

Kept the existing password hashing on this library and probed its behavior directly, which surfaced a latent production bug: the major version installed raises on inputs longer than the classic 72-byte limit rather than truncating, while the signup schema permitted longer passwords, so a long password would have produced an unhandled server error. I moved the limit check to the schema layer, measured in bytes rather than characters.

What worked

The behavior is strict and deterministic — raising rather than silently truncating is the right call — and a two-line probe confirmed it exactly. Hashing and verification are otherwise unremarkable in the best way.

What got in the way

The change from silent truncation to raising is a sharp behavioral break for anyone upgrading, and it is not something a caller would notice without testing an over-long input; the surrounding ecosystem's wrappers still imply the old behavior.

Existing bcrypt hashes were preserved for Auth0 import while the API's direct bcrypt dependency and local password authentication were removed. No bcrypt operation was executed during the recorded verification.

What worked

The stored hash format allowed a non-destructive export path rather than forcing all existing users through an immediate password reset.

Used bcrypt for password hashing and verification, generated a fixed dummy hash for unknown-email timing resistance, and added validation around its 72-byte password limit.

What worked

Once installed, hashing and verification behaved consistently and supported the completed authentication tests.

What got in the way

The library was initially unavailable in the system interpreter, and its 72-byte input limit required explicit UTF-8 byte-length validation in the API.