[deleted]
Okta – Username Above 52 Characters Security Advisory
41–50 of 78 posts
Re: Okta – Username Above 52 Characters Security Advisory
#42This is obviously a huge mistake by Okta (for the love of God understand how your crypto functions work before you apply them) but at the same time, a crypto function with a maximum input length that also auto-truncates the data sounds like bad API design. You are basically asking for someone to goof up and make a mistake. It's much better to implement these things defensively so that the caller doesn't inadvertently…
Agree with the spirit of the argument, but I disagree about the bad design. BCrypt has its trade-offs, you are expected to know how to use it when using it, specially if by choice.
It's like complaining about how dangerous an axe is because it's super sharp. You don't complain, you just don't grab the blade section, you grab it by the handle. And
Re: Okta – Username Above 52 Characters Security Advisory
#43This is obviously a huge mistake by Okta (for the love of God understand how your crypto functions work before you apply them) but at the same time, a crypto function with a maximum input length that also auto-truncates the data sounds like bad API design. You are basically asking for someone to goof up and make a mistake. It's much better to implement these things defensively so that the caller doesn't inadvertently…
Agree with the spirit of the argument, but I disagree about the bad design. BCrypt has its trade-offs, you are expected to know how to use it when using it, specially if by choice. It's like complaining about how dangerous an axe is because it's super sharp. You don't complain, you just don't grab the blade section, you grab it by the handle. And
If your crypto library works like an Axe and the methods aren’t prefixed with “unsafe_”, the library is bad. I would expect an exception when a hashing function gets an argument that’s too long, not just dropping of the excess input. Who thinks that’s the best choice?
Re: Okta – Username Above 52 Characters Security Advisory
#44This is obviously a huge mistake by Okta (for the love of God understand how your crypto functions work before you apply them) but at the same time, a crypto function with a maximum input length that also auto-truncates the data sounds like bad API design. You are basically asking for someone to goof up and make a mistake. It's much better to implement these things defensively so that the caller doesn't inadvertently…
Passing something that isn’t a password + salt into bcrypt is the mistake here.
Re: Okta – Username Above 52 Characters Security Advisory
#45> https://man.openbsd.org/crypt > So if the userid is 18 digits, the username is 52 characters, and the delimiters are 1 character each, then the total length of the non-secret prefix is 72, and bcrypt will drop the secret suffix. You aren’t supposed to put more than the salt and the password into trad unix password hashes.
why would someone in 2024 reach for bcrypt for building a secure hash key?
It seemed the best option I could find for a rp2040 microcontroller when I went looking recently? Perhaps not for okta...
Re: Okta – Username Above 52 Characters Security Advisory
#46Earlier quoted context omitted.
Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$% Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com/!@#$%
A delimiter fixes the problem if you're sure the delimiter character can never be inside the username and password. Better would be to prefix the length of each field. Better still would be separately hashing each field and concatenating the results.
Personally, I like a fixed uint8 or uint16 representing the length of each segment. Then, there are no forbidden characters or quoting required. Maybe I want to have \0 in my password.
Re: Okta – Username Above 52 Characters Security Advisory
#47Earlier quoted context omitted.
No. Such a rainbow table is per-username and non reusable. Which is the point of salting.
No, rainbow tables are hash-input specific. They're user-specific only if the salt is user-unique. Usernames aren't normally part of the hash input because they're assumed-public knowledge. You can test this for yourself by creating a user account, then editing the master password database and manually changing the username without recalculating the password hash. The password will still work. If the username was par…
You complained about them salting using the public username as salt. You asserted that this makes the rainbow table computable offline. I asserted that this didn't matter much for security since the table for H(username || secret) is username specific and not reusable for other usernames. Since precomputed rainbow tables consume quite a bit of space it is rather unlikely that anyone would have such a table stored for any random username.
Re: Okta – Username Above 52 Characters Security Advisory
#48This is written in C, right?
> This is written in C, right? What's your point? That rewriting `bcrypt` in something else magically fixes this? AIUI, the issue is that `bcrypt` only uses the first 72 bytes of the input to create a hash.
The issue is with the user mistaking bcrypt for a general-purpose digest hashing tool.
It's like using a flat-head screwdriver as a hardwood chisel and then the handle breaks off after the third strike.
Re: Okta – Username Above 52 Characters Security Advisory
#49Re: Okta – Username Above 52 Characters Security Advisory
#50Earlier quoted context omitted.
The goal of a salt is to prevent lookup attacks. Since the user id is unique to each user, it prevents the use of pre-computed lookup tables like a salt would.
The security of salting is twofold. Yes, it defeats the common rainbow table. But if the salt is known, a rainbow table for that salt can be computed. The security of salting depends on the salt being unknown. If the salt is externally known, which the username and userID necessarily are, then the rainbow table for that account can be computed entirely offline, defeating the point of salting.
The primary purpose of salting is to prevent precomputation being used to attack all users (e.g. rainbow tables). Even when specific salts are known they have already done this job.
Salts are not intended to be secrets.
If you want to treat a salt as if it was a private key, that would only provide additional protection for the very specific circumstance where the user hash is compromised, but the corresponding salt was not.