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

31–40 of 78 posts

Re: Okta – Username Above 52 Characters Security Advisory

#31

Post by Dylan16807 »

akira2501 wrote: post #28
Dylan16807 wrote: post #22

Earlier quoted context omitted.

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.

I tend to use '\0' as a delimiter for this reason.

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.

Re: Okta – Username Above 52 Characters Security Advisory

#32

Post by pquerna »

EasyMark wrote: post #25
a-dub wrote: post #20

Earlier quoted context omitted.

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

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.

Re: Okta – Username Above 52 Characters Security Advisory

#33

Post by jadengis »

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 make a mistake. Especially with a hashing algorithm, because there is no way to verify that the result is correct.

Re: Okta – Username Above 52 Characters Security Advisory

#34

Post by akira2501 »

Dylan16807 wrote: post #31
akira2501 wrote: post #28

Earlier quoted context omitted.

I tend to use '\0' as a delimiter for this reason.

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 function call. Afterwards they are not needed or significant.

Re: Okta – Username Above 52 Characters Security Advisory

#35

Post by heliosyne »

njtransit wrote: post #15
fanf2 wrote: post #11

Earlier quoted context omitted.

The salt is a separate input to the algorithm that is used differently and usually more restricted than the password.

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.

Re: Okta – Username Above 52 Characters Security Advisory

#36

Post by lmz »

heliosyne wrote: post #35
njtransit wrote: post #15

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

No. Such a rainbow table is per-username and non reusable. Which is the point of salting.

Re: Okta – Username Above 52 Characters Security Advisory

#37

Post by heliosyne »

a-dub wrote: post #20
fanf2 wrote: post #5

> 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?

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 maturity (extensive hostile cryptanalysis), bcrypt stays as one of the better choices even 25 year later.

That said, bcrypt's main limitation is it has a low memory-size cost. There are some newer algorithms that improve on bcrypt by increasing the memory-size cost to more than is practical even for FPGA attacks.

More importantly, bcrypt didn't actually fail here. The vulnerability happened because okta didn't use it correctly. All crypto is insecure if you use it wrong enough.

Re: Okta – Username Above 52 Characters Security Advisory

#38

Post by lelanthran »

Animats wrote: post #16

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

Re: Okta – Username Above 52 Characters Security Advisory

#39

Post by heliosyne »

lmz wrote: post #36
heliosyne wrote: post #35

Earlier quoted context omitted.

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.

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 part of the hash input, the password would fail.

Re: Okta – Username Above 52 Characters Security Advisory

#40

Post by sebastialonso »

ronsor wrote: post #14
fanf2 wrote: post #12

Earlier quoted context omitted.

If the cache gets leaked, you don’t want any miscreants to be able to bruteforce passwords from the cache keys.

Do we need to put the password in the cache key?

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