bcrypt NUL-byte handling may allow equivalent passwords

[oSthing]

While reviewing the hashpw implementation, I noticed behavior that may deserve clarification from a security perspective.

hashpw accepts arbitrary &[u8] as password input, but bcrypt historically processes passwords using C-string semantics and only considers bytes up to the first NUL (0x00) character (and only up to 72 bytes total).

This means the following two inputs may produce identical hashes:

import bcrypt
from os import urandom

def attack(key):
    return key + b"\x00" + key

salt = bcrypt.gensalt()
key = urandom(16)
key1 = attack(key)

hash_key = bcrypt.hashpw(key, salt)
hash_key1 = bcrypt.hashpw(key1, salt)

print(hash_key == hash_key1)   # True
print(bcrypt.checkpw(key1, hash_key))  # True

Although this behavior may be consistent with the original bcrypt design, the current API:

fn hashpw(password: &[u8], salt: &[u8])

suggests that arbitrary binary input is fully supported.

If applications use bcrypt as a generic KDF for binary tokens (API keys, session secrets, etc.), this could lead to credential equivalence where.

Is this behavior intentionally preserved for compatibility?

Should the documentation explicitly warn that NUL bytes terminate effective password

[alex]

I haven't compared in detail with your script, we but explicitly test for this case: https://github.com/pyca/bcrypt/blob/main/tests/test_bcrypt.py#L319-L327

[oSthing]

ok,it clearly demonstrates that the library is sensitive to changes after the first NUL byte, and my initial assumption about simple C-string truncation was incorrect.

I'm still a bit puzzled by the behavior in my original script. Even though it's not truncating at the first NUL, the specific pattern I used (key + b"\x00" + key) still reliably produces the exact same hash as just key.
Since the resulting hashes are perfectly identical and checkpw returns True for both.

[charmander]

Even though it's not truncating at the first NUL, the specific pattern I used (key + b"\x00" + key) still reliably produces the exact same hash as just key.

Yes, bcrypt expands keys to 72 bytes by cycling key + b"\x00", so all keys that are equal when repeated and truncated in that way produce the same hash. (I thought I commented on that when allowing NULs was reintroduced, but maybe not…?)