5 ms·
Okta – Username Above 52 Characters Security Advisory
- djbusby 2y agoConcise write up; not surprising that cache played a part. Can't tell if it's issue with BCrypt or with the state-data going into the key, or combo-cache lookup tho.
- ptcrash 2y agoI think it's more of a logic problem. I suspect the engineers made a false assumption that bcrypt can hash a trivial amount of data like some other hashing algos.
- Forbo 2y agoI'm really sick of companies disclosing this shit late Friday afternoon. Go fuck yourselves. Sincerely, Everyone in the industry
- pluc 2y agoIt's the second time they do that in a few weeks too, _and_ it's not on their security page [1] which promises transparency. [1] https://trust.okta.com/ https://trust.okta.com/
- slama 2y agoIt is listed on their security advisories page, which you can navigate to from that link: https://trust.okta.com/security-advisories/ https://trust.okta.com/security-advisories/
- cyberax 2y agoThank you for your feedback. Next time, we'll disclose it on Saturday evening. -- With Love, Okta.
- chanux 2y agoAlso, are there any repercussions for this kind of stuff? I don't know, fines from the organizations they get compliance certifications from or something.
- _hyn3 2y agoNo repercussions, sadly. Those compliance companies are (mostly) all just checking a box. It's (mostly) security theater from people who wouldn't know security if it bit them in the nether regions. Even if that wasn't true, there's probably no box in any compliance regime that says "Yes, we loudly promulgate our security failures from the nearest rooftop on 10am on a weekday" (and it's always five o'clock somewhere, right?) If it helps (I know it doesn't), the Executive Branch likes to do this with poor job number revisions, too, lol
- hoffs 2y agogeee, nobody is targeting you
- Forbo 2y agoDoesn't have to be targeted for it to be shitty behavior.
- fanf2 2y ago<< The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password. During specific conditions, this could allow users to authenticate by only providing the username with the stored cache key of a previous successful authentication. >> https://man.openbsd.org/crypt https://man.openbsd.org/crypt << The maximum password length is 72. >> 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.
- marginalia_nu 2y ago> You aren’t supposed to put more than the salt and the password into trad unix password hashes. To be fair, they're basically salting with the userid and username. Still unorthodox to be sure.
- fanf2 2y agoThe salt is a separate input to the algorithm that is used differently and usually more restricted than the password.
- njtransit 2y agoThe 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.
- heliosyne 2y agoThe 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.
- Animats 2y agoThis is written in C, right?
- tedunangst 2y agoYour rewrite of bcrypt in not C is unlikely to support longer passwords.
- _hyn3 2y agoNotC, the language that entire operating systems haven't been written in.
- lanstin 2y agoProbably Java. This is not a memory vulnerability but a protocol vulnerability.
- lelanthran 2y ago> 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.
- drbig 2y agoThe 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.
- jadengis 2y agoThis 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 make a mistake. Especially with a hashing algorithm, because there is no way to verify that the result is correct.
- mplewis 2y agoPassing something that isn’t a password + salt into bcrypt is the mistake here.
- ytpete 2y agoEven that sounds potentially dangerous to me now, since it effectively means that some extra-long "correct horse battery stapler"-style passwords could be left effectively unsalted. I mean yeah, 78 chars is an awfully long password but for some famous book or movie quotes maybe not outside the realm of possibility. Or if languages using double-byte characters effectively halve that cutoff then it really becomes an issue...
- sebastialonso 2y agoAgree 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
- echoangle 2y agoIf 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?
- deleted 2y ago[deleted]
- _hyn3 2y agoWhy is anyone actually using Okta for anything these days? IMO, better to choose point solutions and combine them.
- demarq 2y agoWasn’t there a project posted here that can spot this things automatically. It’s was a fuzzer of some sort
- err4nt 2y agoThey had literally 1 job: secure authentication. This isn't the first time Okta has had a gaffe on a level that should cause any customer to reconsider. What's that saying, "Fool me once, shame on thee, fool me twice, shame on me". Don't get fooled by Okta a second, third, or fourth time.