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

61–70 of 78 posts

Re: Okta – Username Above 52 Characters Security Advisory

#61

Post by _hyn3 »

chanux wrote: post #21
Forbo wrote: post #3

I'm really sick of companies disclosing this shit late Friday afternoon. Go fuck yourselves. Sincerely, Everyone in the industry

Also, are there any repercussions for this kind of stuff? I don't know, fines from the organizations they get compliance certifications from or something.

No 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

Re: Okta – Username Above 52 Characters Security Advisory

#62

Post by 0x457 »

jrockway wrote: post #13
0x457 wrote: post #7

Earlier quoted context omitted.

I mean yes overall, but why would put delimeters into hash? you just smash bytes together.

Username: x@example.xyz Password: .com/!@#$% Concatenated: x@example.xyz.com/!@#$% Username: x@example.xyz.com Password: /!@#$% Concatenated: x@example.xyz.com/!@#$%

By why does it matter? It's a one-way hash isn't?

Also, we're talking about user_id not user_email, so it should be the same length always. Well, unless you're silly and using databases sequence for IDs.

Re: Okta – Username Above 52 Characters Security Advisory

#64

Post by [deleted] »

sebastialonso wrote: post #42
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…

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

[deleted]

Re: Okta – Username Above 52 Characters Security Advisory

#65

Post by Dylan16807 »

akira2501 wrote: post #34
Dylan16807 wrote: post #31

Earlier quoted context omitted.

You still need to make sure nulls can't show up, and you need to consider possible truncation scenarios caused by those nulls and make sure they won't cause silent failures at any point.

> You still need to make sure nulls can't show up Which is very easy to do without losing any desired functionality as opposed to delimiters in the ASCII character range. > and you need to consider possible truncation scenarios In particular hashing libraries worth using never have this problem. > and make sure they won't cause silent failures at any point. They literally only need to exist in the data to one functio…

> In particular hashing libraries worth using never have this problem.

I'll note that the reason we're here in the first place is that they were using a password hash library with a completely unacceptable API.

Re: Okta – Username Above 52 Characters Security Advisory

#67

Post by akerl_ »

fanf2 wrote: post #59
3np wrote: post #54

Earlier quoted context omitted.

That should also mean that ca 50-52 character usernames are likely easily bruteforcable. Which makes the preconditions wider than those stated in the publication.

50 letters is 235 bits which is not at all bruteforceable.

They’re saying that if a username is 50 characters, only 2 characters of the password are used to in the cache key. And a 2 character password is very bruteforceable.

Re: Okta – Username Above 52 Characters Security Advisory

#68

Post by its-summertime »

magicalhippo wrote: post #49
sebastialonso wrote: post #40

Earlier quoted context omitted.

Can't believe the answers you're getting. The answer's a big fat NO. If you find yourself in that situation, there's something very incorrect with your design.

So how would you design it instead?

    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

Re: Okta – Username Above 52 Characters Security Advisory

#70

Post by magicalhippo »

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

Earlier quoted context omitted.

So how would you design it instead?

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.
Post reply on HN