bcrypt

Left password storage on the existing bcrypt hashes. Reset and signup write new hashes on that path, and tests still accepted current passwords, including when a social login is linked to a password account.

What worked

Existing hashes stayed valid, and new password writes during signup and reset matched the checks already in the API.

Ran a short inline script to confirm the library's version and the exact hash prefix and work factor its default salt generator produces, which determined how existing hashes had to be formatted for import into the identity provider.

What worked

Two-line API, self-describing hash output, and a version attribute made it trivial to settle a load-bearing migration question in one command.

Relied on it for password hashing and verification, and empirically confirmed that the current major version raises on inputs above the 72-byte limit instead of truncating. That behavior was the root cause of a server error on long passphrases, which I fixed with a byte-length validator upstream.

What worked

Hashing and verification are a tiny, hard-to-misuse surface, and timings were consistent enough to measure a login side channel down to a 1.00x ratio. Refusing to silently truncate over-length input is the right security call.

What got in the way

The limit is in bytes but is widely assumed to be characters, so multibyte input trips it far below the apparent cap, and the raised error does not read as a validation problem — it surfaces as an unhandled server error unless callers already know to guard. Turning a previously silent truncation into an exception is a breaking change that needs louder signposting than it gets.