Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Okta – Username Above 52 Characters Security Advisory

trust.okta.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Okta – Username Above 52 Characters Security Advisory

#71

Post by a-dub »

heliosyne wrote: post #37
a-dub wrote: post #20

Earlier quoted context omitted.

why would someone in 2024 reach for bcrypt for building a secure hash key?

Because bcrypt is still viable. Its cost factor is easily scaled to commodity performance, keeping the attack cost high. The main attack vector these days is GPU-based compute. There, SHA* algorithms are particularly weak because they can be so efficiently computed. Unlike SHA algorithms, bcrypt generates high memory contention, even on modern GPUs. Add in the constraint of broad support, low "honest use" cost, and m…

after all of the headaches in the late 90s/early 2000s with truncating password hash functions, i'm just a little surprised that this sort of thing would still be an issue.

i understand performance concerns and design trade offs, but i would expect a secure hashing function in 2024 to do proper message scheduling and compression or return errors when truncations are happening.

i suppose 90s culture is hip again these days, so maybe this does make sense?

Re: Okta – Username Above 52 Characters Security Advisory

#72

Post by its-summertime »

magicalhippo wrote: post #70
its-summertime wrote: post #68

Earlier quoted context omitted.

key = anyhash(uuid+username) if (result := cache.get(uuid+username)): if hash_and_equality(password, result.password_hash): return result.the_other_stuff # try login or else fail

Some insight into why this is good and why including the password as input in the derivation of the cache key is terrible would be appreciated.

With no password in key: mildly cleaner to drop entries on password change, even if the cache didn't get the command to drop the key, the next login would override the old key's value anyhow, instead of potentially a key per password that was valid in the short period around a password change

Of course, if you have any validness of old sessions / passwords around a password change, you are doing something wrong.

My personal wondering is, considering KDF is meant to be expensive, why is IO more expensive to the point it needs a cache?

Re: Okta – Username Above 52 Characters Security Advisory

#73

Post by magicalhippo »

its-summertime wrote: post #72
magicalhippo wrote: post #70

Earlier quoted context omitted.

Some insight into why this is good and why including the password as input in the derivation of the cache key is terrible would be appreciated.

With no password in key: mildly cleaner to drop entries on password change, even if the cache didn't get the command to drop the key, the next login would override the old key's value anyhow, instead of potentially a key per password that was valid in the short period around a password change Of course, if you have any validness of old sessions / passwords around a password change, you are doing something wrong. My p…

Thanks, good points.

> why is IO more expensive to the point it needs a cache

The advisory mentions it's only exploitable if the upstream auth server is unresponsive. So it seems to be mainly for resilience.

Re: Okta – Username Above 52 Characters Security Advisory

#74

Post by crest »

pquerna wrote: post #32
EasyMark wrote: post #25

Earlier quoted context omitted.

okta has been around longer than a year and momentum keeps a lot of companies from changing anything until catastrophe strikes

per https://trust.okta.com/security-advisories/okta-ad-ldap-dele... > 2024-07-23 - Vulnerability introduced as part of a standard Okta release This issue is not an "okta is old" issue. this was new code written in 2024 that used a password hashing function from 1999 as a cache key.

Bcrypt is still perfectly usable for its original purpose. They just picked/wrote a bad implementation that silently truncated inputs longer than the maximum input length. Would you also ask why they picked AES (a cipher from 1998) when the error was with the user (e.g. picking fixed/too short key)?

Re: Okta – Username Above 52 Characters Security Advisory

#75

Post by ytpete »

mplewis wrote: post #44
jadengis wrote: post #33

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

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

Re: Okta – Username Above 52 Characters Security Advisory

#76

Post by err4nt »

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

Re: Okta – Username Above 52 Characters Security Advisory

#77

Post by appplication »

thiht wrote: post #52
sebastialonso wrote: post #42

Earlier quoted context omitted.

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 passing more than 72 bytes to a function makes it silently fail, it IS bad design, especially for a sensitive, security-related function. The first condition in the function should be `if len(input) > 72 then explicitly fail` Not letting people use your API incorrectly is API design 101. To be clear this is not the fault of the bcrypt algorithm, all algorithms have their limitations. This is the fault of bcrypt li…

There is no other answer than this. Silent failures are never acceptable, even if documented. Because despite what we want to believe about the world, people don’t read the docs, or read them and forget, or read them and misunderstand.
Post reply on HN