[jedisct1]

The bcrypt implementation in the Zig standard library has both the bcrypt() function (where truncation is explicitly documented) and the bcryptWithoutTruncation() function (which is recommended and automatically pre-hashes long passwords).

[n0rdy]

Author here: thanks for reading the post.

It's great to hear that Zig covered both cases. However, I'd still prefer the opposite behavior: a safe (without truncation) default `bcrypt()` and the unsafe function with the explicit name `bcryptWithTruncation()`.

My opinion is based on the assumption that the majority of the users will go with the `bcrypt()` option. Having AI "helpers" might make this statistic even worse.

Do you happen to know Zig team's reasoning behind this design choice? I'm really curious.

[masklinn]

Note that the "safe" version makes very bespoke choices: it prehashes only overlong password, and does so with hmac-sha512 (which it b64-encodes). So it would very much be incompatible with other bcrypt implementations when outside of the "correct space".

These choices are documented in the function's docstring, but not obvious, nor do they seem encoded in a custom version.

[jszymborski]

Sounds like it would then make sense to hide crypto primitives and their footguns under a "hazmat" or "danger" namespace, sorta like webcrypto or libsodium.

So something like crypto.danger.bcrypt and crypto.bcryptWithTruncation

[jedisct1]

`bcrypt()` is bcrypt as implemented everywhere else, and is required for interoperability with other implementations. If you don't truncate, this is not `bcrypt` any more.

`bcryptWithTruncation()` is great for applications entirely written in Zig, but can create hashes that would not verify with other implementations.

The documentation of these functions is very explicit about the difference.

The verification function includes a `silently_truncate_password` option that is also pretty explicit.

[xmprt]

To be fair, I can't think of a single context where I would want to truncate a password before hashing so interoperability with other systems isn't worth letting by a dangerous edge case in my opinion. I'd rather have the system break for the handful of users with a 72+ char password than overlook a potential critical security issue.

[masklinn]

You might need it if you’re porting / reimplementing a system and have to be compatible with an existing base of hashed truncated passwords.

I would agree that it should not just be called “bcrypt” though, likely no function of this module should be, they should either explain their risks or clarify their safety.

Or possibly only a version which fails if passed more than 72 bytes or any nul.

[masklinn]

Seems odd to keep the broken one as the default[0], make the "recommended" one so much longer, and provide none which simply errors on overlong passwords.

Also neither seems to warn about the NUL issue.

[0] I assume for compatibility purpose, but it still seems very dubious.

[IshKebab]

Disappointing that Zig would get the API design wrong too. I would have expected better.

If you don't see the mistake, Google 'yaml.safe_load'.