bcrypt+72+bytes+ValueError

Not specified by the original author.

ValueError: password cannot be longer than 72 bytes

TL;DR: bcrypt 4.1 stopped silently truncating long passwords and now raises ValueError. Pre-hash passwords longer than 72 bytes with SHA-256 before bcrypt, or pin bcrypt==4.0.1 as a stopgap while you migrate.

ValueError: password cannot be longer than 72 bytes

The fix

1. The correct fix, pre-hash before bcrypt:

import hashlib, bcrypt
digest = hashlib.sha256(raw_password).digest()
hashed = bcrypt.hashpw(digest, bcrypt.gensalt())

Do the same digest step when verifying.

2. The stopgap, pin the old behavior:

pip install bcrypt==4.0.1

3. Verify:

python -c "import bcrypt; print(bcrypt.__version__)"

Then hash a long input and confirm no ValueError.

Agent? Search Vectle for more: curl -s 'https://vectle.com/api/v1/search?q=bcrypt+72+bytes+ValueError'

When this applies

• Hashing worked before a bcrypt upgrade to 4.1+.
• passlib's bcrypt backend fails during its version probe.
• Passwords come from user input with no length cap.

When it does NOT apply

• The error is Invalid salt, which is a malformed hash problem.
• You are on bcrypt 4.0.x and want the new behavior; upgrade instead.

Why this happens

bcrypt has always only used the first 72 bytes; older versions just truncated silently, which is arguably worse. 4.1 made it loud so developers notice the data loss. Pre-hashing with SHA-256 preserves all input entropy in the 72-byte window and is the standard workaround recommended by the ecosystem.

Compatibility

bcrypt 4.1+. passlib 1.7.4 trips this in its backend probe; pinning bcrypt==4.0.1 is the common workaround until passlib handles it.

bcrypt 4.1 turned the old silent 72-byte truncation into a hard ValueError, which broke passlib's bcrypt backend probe and any app hashing long passwords. The signifyapp project notes document hitting exactly this error with the pip install bcrypt==4.0.1 workaround, and passlib users hit it through the backend version probe. The correct long-term fix is pre-hashing with SHA-256 before bcrypt, which is what the 72-byte limit has always effectively required.

Not specified by the original author.

TypeError: Unicode-objects must be encoded before hashing

TL;DR: bcrypt wants bytes, you gave it str. Call .encode() on the password before hashpw or checkpw and the error goes away.

TypeError: Unicode-objects must be encoded before hashing

The fix

import bcrypt
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt())
ok = bcrypt.checkpw(password.encode(), hashed)

Verify:

python -c "import bcrypt; h=bcrypt.hashpw('pw'.encode(), bcrypt.gensalt()); print(bcrypt.checkpw('pw'.encode(), h))"

Expected output: True.

Agent? Search Vectle for more: curl -s 'https://vectle.com/api/v1/search?q=bcrypt+Unicode-objects+must+be+encoded'

When this applies

• Passwords arrive as str from a form, JSON body, or input().
• The traceback points at hashpw or checkpw with a str argument.
• First-time bcrypt users in any web framework.

When it does NOT apply

• Invalid salt, which is a bad stored hash.
• password cannot be longer than 72 bytes, which is the length rule.

Why this happens

Hashing is defined over bytes. bcrypt refuses to guess an encoding for you (UTF-8 today, something else tomorrow would silently change every hash), so it raises instead. Encoding explicitly at the boundary keeps hashes reproducible across systems.

Compatibility

All bcrypt versions. UTF-8 via .encode() is the standard choice; just be consistent between hashing and verifying.

bcrypt operates on bytes, not str, so every bcrypt function rejects text input with TypeError: Unicode-objects must be encoded before hashing. This is probably the single most hit bcrypt error for beginners, since web frameworks hand you str passwords and the fix is a single .encode() call. The rule is simple: encode on the way in for both hashpw and checkpw, and keep everything bytes on the bcrypt side of the boundary.

Not specified by the original author.

ModuleNotFoundError: No module named 'bcrypt'

TL;DR: run pip install bcrypt. It was probably only ever a transitive dependency, so add it to your requirements explicitly.

ModuleNotFoundError: No module named 'bcrypt'

The fix

pip install bcrypt

Verify:

python -c "import bcrypt; print(bcrypt.hashpw(b'pw', bcrypt.gensalt())[:7])"

Expected output: a hash prefix like $2b$12$.

Agent? Search Vectle for more: curl -s 'https://vectle.com/api/v1/search?q=bcrypt+No+module+named+pip+install'

When this applies

• Fresh virtualenvs, containers, or CI runners.
• passlib or Flask-Bcrypt installed without bcrypt coming along.
• The package worked locally because something else pulled it in.

When it does NOT apply

• DLL load failed while importing _bcrypt, which is the broken-wheel problem.
• password cannot be longer than 72 bytes, which is the 4.1 behavior change.

Why this happens

Transitive dependencies are invisible until the thing that pulled them in is removed or upgraded. bcrypt is the classic case: apps use it through passlib for years, then a fresh install without passlib's bcrypt extra leaves it missing. Depending on it directly is the fix.

Compatibility

bcrypt 4.x on all supported Pythons. Ships wheels for Windows, macOS, and Linux.

bcrypt is one of the most depended-upon password-hashing libraries in Python, pulled in by passlib, Flask-Bcrypt, and countless apps, yet it is frequently absent from fresh virtualenvs, containers, and CI runners because it was only ever a transitive dependency. The PyPI page documents pip install bcrypt. Here the names match, so this is always a missing-requirement problem, not a naming trap.