Okta Bcrypt incident lessons for designing better APIs

Re:Okta Bcrypt incident lessons for designing better APIs by jedisct1 on Wednesday February 05, 2025 @05:06PM (#42955957)

`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.

[ Parent | on HN ]

Re:Okta Bcrypt incident lessons for designing better APIs by xmprt on Wednesday February 05, 2025 @05:58PM (#42956585)

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.

[ Parent | on HN ]

Re:Okta Bcrypt incident lessons for designing better APIs by masklinn on Thursday February 06, 2025 @04:55AM (#42960811)

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.

[ Parent | on HN ]