Okta Bcrypt incident lessons for designing better APIs
1–10 of 169 posts
Re: Okta Bcrypt incident lessons for designing better APIs
#2The 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).
Re: Okta Bcrypt incident lessons for designing better APIs
#3Bcrypt is a password hash, not a KDF, which is the way it was used in this API. It's super unclear to me why they wanted a string-based KDF here at all; does anyone have more context?
I've in the past been annoying about saying I think we should just call all password hashes "KDFs", but here's a really good illustration of why I was definitely wrong about that. A KDF is a generally-useful bit of cryptography joinery; a password hash has exactly one job.
Re: Okta Bcrypt incident lessons for designing better APIs
#4The 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).
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.
Re: Okta Bcrypt incident lessons for designing better APIs
#5I am curious why bcrypt was used for hashing in the first place and not something like sha-512
Is there a reason I might be missing?
Re: Okta Bcrypt incident lessons for designing better APIs
#6> was used to generate the cache key where we hash a combined string of userId + username + password.
Don't conceive your own cryptographic hacks. Use existing KDF designed by professionals.
Re: Okta Bcrypt incident lessons for designing better APIs
#7damn that sounds like a rookie mistake for an organization who is literally in the business of secure auth
Re: Okta Bcrypt incident lessons for designing better APIs
#8I am curious why bcrypt was used for hashing in the first place and not something like sha-512 Is there a reason I might be missing?
Yes, the hashed payload contained a password, so presumably they didn't want to just SHA it.
Re: Okta Bcrypt incident lessons for designing better APIs
#9I am curious why bcrypt was used for hashing in the first place and not something like sha-512 Is there a reason I might be missing?
There is a discussion about that on the security stackexchange (https://security.stackexchange.com/questions/133239/what-is-...).
The TLDR:
> SHA-2 family of hashes was designed to be fast. BCrypt was designed to be slow.
Slow == harder to brute-force == more secure.
Re: Okta Bcrypt incident lessons for designing better APIs
#10The 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).
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.