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

81–90 of 169 posts

Re: Okta Bcrypt incident lessons for designing better APIs

#81

Post by re-thc »

smw wrote: post #55
tptacek wrote: post #45

Earlier quoted context omitted.

I feel like the "authentication company should have known" thing is unuseful; most developers at "security" companies are just ordinary generalist developers. Ironically, I think they boned themselves by trying to be too clever here, not too casual.

You don't think a company whose entire reason for being is providing security services for other companies should have designs related to authentication reviewed by security experts?

> You don't think a company whose entire reason for being...

That's the assumption everyone makes and it's dangerous.

The fact that someone or some entity does something and only special doesn't make them the best at it (or even close). It's just what they do to survive (and earn).

Re: Okta Bcrypt incident lessons for designing better APIs

#82

Post by Dylan16807 »

zorgmonkey wrote: post #38
CJefferson wrote: post #33

Earlier quoted context omitted.

On the other hand, why not have implementations assert if they are given a string longer than 72 chars? It feels to me like no-one would ever do that on purpose, so it's a massive issue which is easy to accidentally make with a really important function.

It is almost never I good idea to assert in a library, unless the error is truly unrecoverable. I think returning an error code\throwing an exception would be very reasonable and a much better API than failing silently though.

An exception is fine if the language has them. I don't think "assert" was meant super literally and exactly the way C does it.

An error code is risky.

Re: Okta Bcrypt incident lessons for designing better APIs

#83

Post by sandeepkd »

I enjoyed the article and the detailed analysis for different languages. The conclusion is probably the part where most of the disagreement lies. API design is is not really at fault here if we consider the purpose of the API and the intended output.

The API was designed to generate a hash for a password (knowledge factor) and for performance and practical reasons a limit has been picked up (72). The chances that some one knows your first 72 characters of password implies that the probably is a lot higher for the abuser to have remaining characters too.

While smaller mistake here in my opinion was not knowing the full implementation details of a library, the bigger mistake was trying to use the library to generate hash of publicly available/visible information

Re: Okta Bcrypt incident lessons for designing better APIs

#84

Post by sandeepkd »

tptacek wrote: post #3

Bcrypt is a password hash, not a KDF, which is the way it was used in this API. It's super unclear to me why they wanted a string-based KDF here at all; does anyone have more context? I've in the past been annoying about saying I think we should just call all password hashes "KDFs", but here's a really good illustration of why I was definitely wrong about that. A KDF is a generally-useful bit of cryptography joinery;…

Hypothetically here is one way it might have played out

Product - we need to provide service availability even if the AD is down

Engineer - Ok, may be we can store the ~credentials in cache

Security - oh, in that case make sure everything in cache is hashed properly with the recommended Bcrypt algorithm

Engineer - We got the approval from the security, we are in much safer zone, lets deliver and get a win

Re: Okta Bcrypt incident lessons for designing better APIs

#86

Post by riffraff »

pclmulqdq wrote: post #25
tptacek wrote: post #24

Earlier quoted context omitted.

Or just a hash of the bcrypt hash, for the password! I don't like using thought-stopping cliches any more than anybody else does, but this design feels a little cargo-culted. All this stuff follows the more fundamental question of "why is the password mixed into a cache key"?

Yeah, I think both of the following would have worked if they wanted the password involved in a cache key and they wanted bcrypt to be used: * bcrypt(SHA-512(PW || stuff)) * SHA(stuff || bcrypt(PW)) Disclaimer: Not cryptography advice. It's still unclear to me why the password is in there.

Perhaps the password is used as part of the cache Key so that a password update implicitly invalidates the cache?

Re: Okta Bcrypt incident lessons for designing better APIs

#87

Post by bux93 »

progmetaldev wrote: post #44

Reminds me of when I saw a junior developer calling SHA-1 on an incrementing integer ID, with no salt. We had a long talk about it, he thought it was too "scrambled" to allow anyone to recognize what was being done. He shouldn't have been so junior, he was 4 or 5 years into his career. I had to be the bad guy and override his decision without further discussing why it was a bad idea, and I really tried for a good 45…

Ah, the tale I could tell you about "encrypted ZIP codes".

Re: Okta Bcrypt incident lessons for designing better APIs

#88

Post by a-dub »

underdeserver wrote: post #85

Hold on, in the Rust example, how does `err_on_truncation` get set? TFA completely ignored that there's a setting somewhere (probably incorrectly defaulting to false)

the rust library exposes a handful of "non_truncating_*" functions that enable error handling. i would expect this to be for drop-in compatibility with old code.

amusingly, the python "library" is just a thin wrapper around the same rust library.

protip: a lot of cryptography primitives actually aren't that complicated in terms of the code itself (and often can be quite elegant, compact and pleasing to the eye). if it's important, probably worth just reading it.

it's what people wrap them with or the systems they build that get messy!

Re: Okta Bcrypt incident lessons for designing better APIs

#89

Post by tptacek »

pclmulqdq wrote: post #76
Vecr wrote: post #74

Earlier quoted context omitted.

SHA-3 has more internal state, it really is plausibly better at handling very large data. If 'unlimited' is really less than a gigabyte, there's no problem. It's mostly the preimage series of attacks and length extension at that point. SHA-3 is better on those. SHA-512 has zero length extension attack resistance.

Internal state length may be a bit of a red herring (note that SHA-3 makes up for that longer internal state by ingesting more data per round), but SHA-3 probably has a higher security margin than the SHA-2 construction mostly because we have had sponge constructions for less time than we have had Merkle-Damgard constructions. NIST basically forced a higher security margin on SHA-3. You are correct about the length e…

Ew. Just HMAC. Don't use truncated SHA2.

Re: Okta Bcrypt incident lessons for designing better APIs

#90

Post by taurknaut »

bufferoverflow wrote: post #77
taurknaut wrote: post #62

Earlier quoted context omitted.

> but they wanted a hash function with unlimited input size I'm kind of baffled how they came to use bcrypt for this. Bcrypt is not exactly subtle about only supporting 72 bytes of input. And this is at a company who provides auth as a service; I've got to imagine they had multiple engineers who knew this (I guess not working on that code). Hell, I know this and I've only used bcrypt twice and I'm nowhere near a secu…

BCrypt should loudly fail if more than 72 bytes are sent to its input.

Maybe it should. Discarding the rest of the bytes works fine for passwords, though. I guess that's just not sufficient.
Post reply on HN