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

A look at Cloudflare's AI-coded OAuth library

neilmadden.blog

Post reply on HN
Print view View original

11–20 of 170 posts

Re: A look at Cloudflare's AI-coded OAuth library

#11

Post by ranguna »

croes wrote: post #3
CuriouslyC wrote: post #2

Mostly a good writeup, but I think there's some serious shifting the goalposts of what "vibe coded" means in a disingenuous way towards the end: 'Yes, this does come across as a bit “vibe-coded”, despite what the README says, but so does a lot of code I see written by humans. LLM or not, we have to give a shit.' If what most people do is "vibe coding" in general, the current definition of vibe coding is essentially m…

Isn’t vibe coding just C&P from AI instead of Stack Overflow? I read it as: done by AI but not checked by humans.

Yep I see it like that as well, code with 0 or very close to 0 interactions from humans. Anyone who wants to change that meaning is not serious.

Re: A look at Cloudflare's AI-coded OAuth library

#12

Post by JimDabell »

SiempreViernes wrote: post #5

A very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system > There are some tests, and they are OK, but they are woefully inadequate for what I would expect of a critical auth service. Testing every MUST and MUST NOT in the spec is a bare minimum, not to mention as many abuse cases as you can think of, but none of that is here…

> A very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system

It does not illustrate that at all.

> Claude's output was thoroughly reviewed by Cloudflare engineers with careful attention paid to security and compliance with standards.

> To emphasize, *this is not "vibe coded"*. Every line was thoroughly reviewed and cross-referenced with relevant RFCs, by security experts with previous experience with those RFCs.

— https://github.com/cloudflare/workers-oauth-provider

The humans who worked on it very, very clearly took responsibility for code quality. That they didn’t get it 100% right does not mean that they “blindly offloaded responsibility”.

Perhaps you can level that accusation at other people doing different things, but Cloudflare explicitly placed the responsibility for this on the humans.

Re: A look at Cloudflare's AI-coded OAuth library

#13

Post by crashabr »

JimDabell wrote: post #12
SiempreViernes wrote: post #5

A very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system > There are some tests, and they are OK, but they are woefully inadequate for what I would expect of a critical auth service. Testing every MUST and MUST NOT in the spec is a bare minimum, not to mention as many abuse cases as you can think of, but none of that is here…

> A very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system It does not illustrate that at all. > Claude's output was thoroughly reviewed by Cloudflare engineers with careful attention paid to security and compliance with standards. > To emphasize, *this is not "vibe coded"*. Every line was thoroughly reviewed and cross-refer…

Studies have shown that the more people use automated systems, the more they start to trust them, leaving to oversight. It's called [automation bias](https://en.m.wikipedia.org/wiki/Automation_bias).

If a Cloudflare security engineer ends up missing the use of a deprecated functionality during a public experiment where they know they'll face very intense scrutiny, what will happen down the line, when llm use is normalized in security contexts?

Re: A look at Cloudflare's AI-coded OAuth library

#14

Post by [deleted] »

JimDabell wrote: post #12
SiempreViernes wrote: post #5

A very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system > There are some tests, and they are OK, but they are woefully inadequate for what I would expect of a critical auth service. Testing every MUST and MUST NOT in the spec is a bare minimum, not to mention as many abuse cases as you can think of, but none of that is here…

> A very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system It does not illustrate that at all. > Claude's output was thoroughly reviewed by Cloudflare engineers with careful attention paid to security and compliance with standards. > To emphasize, *this is not "vibe coded"*. Every line was thoroughly reviewed and cross-refer…

[deleted]

Re: A look at Cloudflare's AI-coded OAuth library

#15

Post by chrismorgan »

belter wrote: post #10

"...A more serious bug is that the code that generates token IDs is not sound: it generates biased output. This is a classic bug when people naively try to generate random strings, and the LLM spat it out in the very first commit as far as I can see. I don’t think it’s exploitable: it reduces the entropy of the tokens, but not far enough to be brute-forceable. But it somewhat gives the lie to the idea that experience…

Admittedly I have done some cryptographic string generation based on different alphabet sizes and characteristics a few years ago, which is pretty specifically relevant, and I’m competent at cryptographic and security concerns for a layman, but I certainly hope security reviewers will be more skilled at these things than me.

I’m very confident I would have noticed this bias in a first pass of reviewing the code. The very first thing you do in a security review is look at where you use `crypto`, what its inputs are, and what you do with its outputs, very carefully. On seeing that %, I would have checked characters.length and found it to be 62, not a factor of 256; so you need to mess around with base conversion, or change the alphabet, or some other such trick.

This bothers me and makes me lose confidence in the review performed.

Re: A look at Cloudflare's AI-coded OAuth library

#16

Post by thegeomaster »

chrismorgan wrote: post #15
belter wrote: post #10

"...A more serious bug is that the code that generates token IDs is not sound: it generates biased output. This is a classic bug when people naively try to generate random strings, and the LLM spat it out in the very first commit as far as I can see. I don’t think it’s exploitable: it reduces the entropy of the tokens, but not far enough to be brute-forceable. But it somewhat gives the lie to the idea that experience…

Admittedly I have done some cryptographic string generation based on different alphabet sizes and characteristics a few years ago, which is pretty specifically relevant, and I’m competent at cryptographic and security concerns for a layman, but I certainly hope security reviewers will be more skilled at these things than me. I’m very confident I would have noticed this bias in a first pass of reviewing the code. The…

But... is it a real problem? As the author says, the entropy reduction is tiny.

Re: A look at Cloudflare's AI-coded OAuth library

#17

Post by dimitri-vs »

techpression wrote: post #4
CuriouslyC wrote: post #2

Mostly a good writeup, but I think there's some serious shifting the goalposts of what "vibe coded" means in a disingenuous way towards the end: 'Yes, this does come across as a bit “vibe-coded”, despite what the README says, but so does a lot of code I see written by humans. LLM or not, we have to give a shit.' If what most people do is "vibe coding" in general, the current definition of vibe coding is essentially m…

I find ”vibe coding” to be one of the, if not the, concepts in this business to lose its meaning the fastest. Similar to how everything all of a sudden was ”cloud” now everything is ”vibe coded”, even though reading the original tweet really narrows it down thoroughly.

IMO it's pretty clear what vibe coding is: you don't look at the code, only the results. If you're making judgement on the code, it's not vibe coding.

Re: A look at Cloudflare's AI-coded OAuth library

#18

Post by afro88 »

> What this interaction shows is how much knowledge you need to bring when you interact with an LLM. The “one big flaw” Claude produced in the middle would probably not have been spotted by someone less experienced with crypto code than this engineer obviously is. And likewise, many people would probably not have questioned the weird choice to move to PBKDF2 as a response

For me this is the key takeaway. You gain proper efficiency using LLMs when you are a competent reviewer, and for lack of a better word, leader. If you don't know the subject matter as well as the LLM, you better be doing something non-critical, or have the time to not trust it and verify everything.

Re: A look at Cloudflare's AI-coded OAuth library

#19

Post by bandoti »

djoldman wrote: post #6

> At ForgeRock, we had hundreds of security bugs in our OAuth implementation, and that was despite having 100s of thousands of automated tests run on every commit, threat modelling, top-flight SAST/DAST, and extremely careful security review by experts. Wow. Anecdotally it's my understanding that OAuth is ... tricky ... but wow. Some would say it's a dumpster fire. I've never read the spec or implemented it.

Honestly, new code always has bugs though. That’s pretty much a guarantee—especially if it’s somewhat complex.

That’s why companies go for things that are “battle tested” like vibe coding. ;)

Joke aside—I like how Anthropic is using their own product in a pragmatic fashion. I’m wondering if they’ll use it for their MCP authentication API.

Re: A look at Cloudflare's AI-coded OAuth library

#20

Post by aiono »

I agree with the last paragraph about doing this yourself. Humans have tendency to take shortcuts while thinking. If you see something resembling what you expect for the end product you will be much less critical of it. The looks/aesthetics matter a lot on finding problems with in a piece of code you are reading. You can verify this by injecting bugs in your code changes and see if reviewers can find them.

On the other hand, when you have to write something yourself you drop down to slow and thinking state where you will pay attention to details a lot more. This means that you will catch bugs you wouldn't otherwise think of. That's why people recommend writing toy versions of the tools you are using because writing yourself teaches a lot better than just reading materials about it. This is related to know our cognition works.

Post reply on HN