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

Okta Bcrypt incident lessons for designing better APIs

n0rdy.foo

Post reply on HN
Print view View original

161–169 of 169 posts

Re: Okta Bcrypt incident lessons for designing better APIs

#161

Post by eesmith »

SebFender wrote: post #58
bawolff wrote: post #48

> On the other hand, such long usernames are not very usual, which I agree with Weird take. Usernames are often chosen by the user. Less so in corporate world but definitely not unheard of

Many of my usernames at my company are based on my email and it's pretty long - by the time you add the domain it's a good 47 characters...

I was at a Python conference once and met someone whose email ended '@boehringer-ingelheim.com'. That's 25 letters right there.

https://www.boehringer-ingelheim.com/media-stories/press-rel... has a camilla.krogh_lauritzen@boehringer-ingelheim.com at 48 characters, for example.

Re: Okta Bcrypt incident lessons for designing better APIs

#162

Post by pornel »

hansvm wrote: post #157
pornel wrote: post #150

Earlier quoted context omitted.

Yikes. It's valid to assume "it will never happen" for 128 bits or more (if the hash function isn't broken) since chance of a random collision is astronomically small, but a collision in 64 bits is within realm of possibility (50% chance of hitting a dupe among 2^32 items).

> valid, 128 bits The birthday paradox is a thing. If you have 128 bits of entropy, you expect the 50% mark to be proportional to 64-bit keys, not 128 bits. 64 bits is a lot, but in my current $WORK project if I only had 128 bits of entropy the chance of failure any given year would be 0.16%. That's not a lot, but it's not a negligible amount either. Bigger companies care more. Google has a paper floating around abou…

I agree that 128 bits is on the lower end of "never", but you still need to store trillions of hashes to have a one-in-a-trillion chance to see a collision (and that's already the overall probability, you don't multiply it by the number of inserts to get 1:1 chance :) I don't think anybody in the world has ever seen a collision of a cryptographically strong 128-bit hash that wasn't a bug or attack.

Birthday paradox applies when you store the items together (it's a chance of collision against any existing item in the set), so overall annual hashing churn isn't affected (more hashes against a smaller set doesn't increase your collision probability as quickly).

Re: Okta Bcrypt incident lessons for designing better APIs

#163

Post by hansvm »

pornel wrote: post #162
hansvm wrote: post #157

Earlier quoted context omitted.

> valid, 128 bits The birthday paradox is a thing. If you have 128 bits of entropy, you expect the 50% mark to be proportional to 64-bit keys, not 128 bits. 64 bits is a lot, but in my current $WORK project if I only had 128 bits of entropy the chance of failure any given year would be 0.16%. That's not a lot, but it's not a negligible amount either. Bigger companies care more. Google has a paper floating around abou…

I agree that 128 bits is on the lower end of "never", but you still need to store trillions of hashes to have a one-in-a-trillion chance to see a collision (and that's already the overall probability, you don't multiply it by the number of inserts to get 1:1 chance :) I don't think anybody in the world has ever seen a collision of a cryptographically strong 128-bit hash that wasn't a bug or attack. Birthday paradox a…

Based on currently available public estimates, Google stores around 2^75 bytes, most of that backed by a small number of very general-purpose object stores. A lot of that is from larger files, but you're still approaching birthday-paradox numbers for in-the-wild 128-bit hash collisions.

Re: Okta Bcrypt incident lessons for designing better APIs

#164

Post by hansvm »

GoblinSlayer wrote: post #160
hansvm wrote: post #157

Earlier quoted context omitted.

> valid, 128 bits The birthday paradox is a thing. If you have 128 bits of entropy, you expect the 50% mark to be proportional to 64-bit keys, not 128 bits. 64 bits is a lot, but in my current $WORK project if I only had 128 bits of entropy the chance of failure any given year would be 0.16%. That's not a lot, but it's not a negligible amount either. Bigger companies care more. Google has a paper floating around abou…

Hashtables have collisions because they don't use all bits of hash, they calculate index=hash%capacity. It doesn't matter, how you calculate the hash, if you have only a few places to insert an item, they will collide.

Right, but the problem they were describing was storing the "hash" in a hash table, not storing the item using a hash. For that, it absolutely matters, and the fact that it was a 128-bit hash IMO isn't good enough because the hash function itself likely sucks.

Re: Okta Bcrypt incident lessons for designing better APIs

#165

Post by nabla9 »

ludwik wrote: post #156
nabla9 wrote: post #106

Earlier quoted context omitted.

The use case was KDF and they decided to do simple password hash signature hack instead by combining strings. They fucked it up.

Of course they fucked it up, as evidenced by their bad security incident. The only question is whether you can really chalk this particular one up to a problem with "rolling your own crypto." That mantra exists for a reason, but it doesn’t feel like it really applies this time. It seems more like they used established crypto—just not the right one for this particular use case.

Concatenating strings before giving it to the hash function instead of using KFD is rolling your own.

Re: Okta Bcrypt incident lessons for designing better APIs

#166

Post by nyclounge »

pclmulqdq wrote: post #21
masklinn wrote: post #20

Earlier quoted context omitted.

They clearly wanted something stronger than "a hash function" or they'd have reached for weaker cryptographic hashes.

They wanted a hard-to-compute cryptographic hash function. Today, that means bcrypt or something with a KDF construction. However, they needed one with unlimited input size, which rules out bcrypt.

Would scrypt solve this problem? Or is it same as bcrypt? Or is scrypt depending on the hardware?

Re: Okta Bcrypt incident lessons for designing better APIs

#167

Post by BrandoElFollito »

zero_k wrote: post #134

Another incident at Okta? Oh no! Its security has _always_ been a mess. It's a dumpster fire and no client of their cares because their identity systems are so messed up, that it's better to have the mess of Okta, than the mess they are sitting on. It's kinda crazy they get away with such incredibly bad security practices. Like... this bcrypt issue has been know for a LONG while. We used to test for it 8-10 years ago…

> no client of their cares because their identity systems are so messed up, that it's better to have the mess of Okta, than the mess they are sitting on

Yes, this is very true.

Also some companies realize that they can screw up royally because they do no have the proper knowledge, and authentication is not a core business of theirs.

I can understand them. I also use mail systems I am not that happy with, but I have this comforting idea that if they have a problem, 3B people are waiting together with me for it to be solved, and that's the kind of pressure that helps.

Re: Okta Bcrypt incident lessons for designing better APIs

#168

Post by veqq »

[u/forgot-CLHS](https://www.reddit.com/r/lisp/comments/1ikrz1g/shout_out_to_...) notes that Common Lisp's defact standard cryptography library Ironclad's [implementation](https://github.com/sharplispers/ironclad/blob/master/src/kdf...) avoids such problems!

``` (defmethod derive-key ((kdf bcrypt) passphrase salt iteration-count key-length) (declare (type (simple-array (unsigned-byte 8) (*)) passphrase salt)) (unless (<= (length passphrase) 72) (error 'ironclad-error :format-control "PASSPHRASE must be at most 72 bytes long."))...) ```

Re: Okta Bcrypt incident lessons for designing better APIs

#169

Post by Zamicol »

tptacek wrote: post #131
Zamicol wrote: post #101

Earlier quoted context omitted.

Password hash functions are designed to be slow, are designed to be use with salts, and may have low entropy inputs. Being slow is a waste for (true) KDFs, salts aren't relevant (although nonces may be), and are designed for high entropy inputs. The naming overlap between the two is bad, so the industry has tried to move towards naming the two differently. Password hashing functions are not ideal KDFs, even though a…

String KDFs are also slow. That's the basic strategy for making high-entropy keys out of low-entropy inputs.

Password hash functions are intentionally designed to be extremely slow (at an exponential scale). While this makes perfect sense for password hashing, it is nonsensical to have such an intentional, configurable slowdown mechanism in KDFs. KDFs have computational cost, but having the kind of extreme slowdown that password hash functions have makes no sense for purpose designed KDFs, especially when needing to derive many keys.
Post reply on HN