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

51–60 of 78 posts

Re: Okta – Username Above 52 Characters Security Advisory

#51

Post by heliosyne »

lmz wrote: post #47
heliosyne wrote: post #39

Earlier quoted context omitted.

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…

I didn't complain about anyone. The Okta vulnerability isn't because of public salts.

Re: Okta – Username Above 52 Characters Security Advisory

#52

Post by thiht »

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

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 libs everywhere, when they implement bcrypt, they should add this check, and maybe offer an unsafe_ alternative without the check.

Re: Okta – Username Above 52 Characters Security Advisory

#53

Post by paulddraper »

fanf2 wrote: post #12
ronsor wrote: post #10

Earlier quoted context omitted.

Why do we need a KDF for a cache key? Won't a normal cryptographic hash function (or its HMAC variant) suffice?

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

Isn't the whole point of using bcrypt is that you can't bruteforce the password?

Re: Okta – Username Above 52 Characters Security Advisory

#54

Post by 3np »

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.

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.

Re: Okta – Username Above 52 Characters Security Advisory

#55

Post by brianshaler »

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…

Re the second quote and response:

One pattern I bump up against from time to time is the delta between using a perfectly defensible technique for a given use-case (safe delimiters when constructing an input for a specific function) versus a desire to have each decision be driven by some universal law (e.g. "if you're streaming data between services, using null bytes as delimiters might not be safe if consuming services may truncate at null bytes, so NEVER use null bytes as delimiters because they can be unsafe")

It's not even a matter of one "side" being right or wrong. You can simultaneously be right that this is perfectly safe in this use-case, while someone else can be right to be concerned ("need to consider possible") because the code will forever be one refactor or copy/paste away from this concatenated string being re-used somewhere else.

Re: Okta – Username Above 52 Characters Security Advisory

#56

Post by chiph »

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.

You're both right, but are coming at this from different directions. In the past a rainbow table was intended to reveal as many passwords on a system as possible once you got a copy of the passwords. If one of them happened to be a high-value account, great. But maybe access to an ordinary account is good enough for their (nefarious) purposes.

It's also possible to build a rainbow table when you already know an account is high-value and have the salt. You can't go download that rainbow table - you'll have to compute it yourself, so the cost to the attacker is higher. But if the account is valuable enough to justify targeting specifically, you'll do it.

Re: Okta – Username Above 52 Characters Security Advisory

#57

Post by notpushkin »

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.

> then the rainbow table for that account can be computed entirely offline

So you basically bruteforce the password for a specific account before you get the actual hash but after you know the hashing scheme? I don’t see how this helps with any sort of attack though.

Re: Okta – Username Above 52 Characters Security Advisory

#58

Post by vlovich123 »

lmz wrote: post #47
heliosyne wrote: post #39

Earlier quoted context omitted.

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…

You can still build a rainbow table for a specific username if you want to do a targeted attack.

Re: Okta – Username Above 52 Characters Security Advisory

#59

Post by fanf2 »

3np wrote: post #54
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.

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