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

Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

herrjemand.medium.com

Post reply on HN
Print view View original

161–170 of 294 posts

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#161

Post by ehutch79 »

gsich wrote: post #158
ehutch79 wrote: post #147

Earlier quoted context omitted.

that 200ms rtt does matter to users. it becomes very noticeable. especially when you're writing an app, not a brochure site. You need to tree shake so you're not serving a huge spa all at once. I've see much worse times for users, and a cdn absolutely help with our staff in asia dealing with our internal apps. Of course they're not always tripping up cloudflare and being shown captchas. I almost _never_ see a cloudfl…

What use has an app that requires a full RTT fot every buttonpress?

None? Why would every button press require a full rtt?

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#162

Post by ehutch79 »

floatboth wrote: post #155
ehutch79 wrote: post #135

Earlier quoted context omitted.

How do you mitigate ddos attacks and other bad actors hitting a page? What does your cdn solution look like? Route optimization from your (single) endpoint to clients literally half a world away?

For regular public web pages , serving the actual fucking page should not be more expensive than serving the captcha page! What the hell is a "bad actor" in relation to GET requests to a public page ? To a public page , all actors should be inherently neutral.

There's a lot of potential side effects. Not every GET request retrieves a static asset. A list view with filters for instance. Either way, you could be dumping any arbitrary data along with a request. Or just try fuzzing parameters. some pages might be poorly done graphQL endpoints, and your might find your db tied up. There are MANY ways a legit a get request can cause issues, let alone someone with bad intentions.

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#163

Post by tomjen3 »

ComodoHacker wrote: post #80

Is CAPTCHA a necessity only in ad-sponsored web? Is there other compelling use-case for it? Can we make CAPTCHA obsolete with decent micropayments solution, when you pay for every transaction with every website, just like we pay for every drop of water we use? Perhaps ISPs could handle it for us?

Captchas, or some anti-bot software is still needed whenever we deal with credit cards, because we are still using the obsolete version where, if you get your hands on the numbers , you can charge any amount you want to whomever you want, instead of a model where your card digitally signs the payment request for the given amount and receiver, which would mean that any theft is pointless.

Anti-bot measures are also used to try to prevent password guessing on e.g the login site to gmail.

Finally, sometimes some places offer things like tickets that go very quickly, in which case having a bot reload the page means the tickets are likely to go to somebody owning a bot rather than a fan of the performer.

None of these cases are solved by payments, they are solved by client side certificates and, in the last case, by requiring the name of the people who are to use the ticket.

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#164

Post by rudedogg »

I'm so fed up with reCAPTCHA. ~90% of the time it doesn't work on desktop Safari (I can see CORS errors in the console), so I have to use a different browser. Even Gumroad won't let me buy things due to this. It really feels like an anti-competitive "bug" (read feature), and is so annoying it's hard to not just give up and use Chrome.

I feel like I'm crazy – no one else complains. I've mentioned @GumRoad on twitter but nothing.

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#165

Post by vidarh »

midev wrote: post #123
vidarh wrote: post #121

Earlier quoted context omitted.

If people intend this to happen, sure . But how many people who put their sites behind Cloudflare is aware that this might be a side effect?

I would wager that most people that purchase Cloudflare are probably aware of the features it offers

Note the distinction. I'd wager that the vast majority of sites behind Cloudflare are not paying customers, and have not paid much attention beyond "hides my server IP slightly and stops DDOS's", without having thought more - or at all - about the wider implications.

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#166

Post by djoldman »

floatboth wrote: post #154
djoldman wrote: post #145

Can a FIDO key be implemented in software? Can you write a program to register a FIDO key as a multi-factor authentication device with a Google account? Or is there some repository of all allowed devices with identifiers? Intuitively that'd be the only way to prevent infinite virtual devices..

Attestation (what they use) is orthogonal to authentication. Token manufacturers have per-batch keys, private key being in the devices of that batch, so sites can verify that your device is from that batch of that vendor. You "can" implement attestation with your own key in software or in whatever, but Cloudflare won't trust your key :D

So how does cloudflare know to not trust your key? They know some secrets from the token manufacturers and test your response against them?

If so, what if the secrets get out? Then all the keys in those batches are poisoned?

Isn't this just some sort of side channel certificate authority?

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#167

Post by gsich »

ehutch79 wrote: post #161
gsich wrote: post #158

Earlier quoted context omitted.

What use has an app that requires a full RTT fot every buttonpress?

None? Why would every button press require a full rtt?

>that 200ms rtt does matter to users. it becomes very noticeable. especially when you're writing an app, not a brochure site. You need to tree shake so you're not serving a huge spa all at once.

Because this implies that.

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#168

Post by stickfigure »

ehutch79 wrote: post #150
stickfigure wrote: post #142

Reading CF's blog announcement [1], this is really horrifying. It trains users to insert security keys and accept biometric identification requests when visiting random web pages, on random untrusted domains. This cannot possibly end well. [1]: https://blog.cloudflare.com/introducing-cryptographic-attest...

Isn't part of the point is that a phishing site wouldnt get the same response as a legit site, and therefore it's be useless to do that, so this behavior is ok?

It's not about phishing, it's about getting the user to blindly accept security checks. If users are trained to insert their usb key / scan their fingerprint whenever they see a cloudflare page, bad actors can present a mockup of this page to exploit that reaction.

Physical keys (and biometrics) work well because they are rarely called for, and the user knows they are doing something security sensitive. "This random page asked me to insert my security key" can't be healthy.

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#169

Post by aseipp »

grishka wrote: post #143
ehutch79 wrote: post #135

Earlier quoted context omitted.

How do you mitigate ddos attacks and other bad actors hitting a page? What does your cdn solution look like? Route optimization from your (single) endpoint to clients literally half a world away?

As I user, I simply don't care. I repeatedly get punished for doing nothing wrong. It's almost like airport security. > What does your cdn solution look like? > Route optimization from your (single) endpoint to clients literally half a world away? And as a developer, I don't understand this newfangled obsession over CDNs either. Yes, there will be 200 ms RTT in some cases. So what? Get over it. Optimize your website…

> Yes, there will be 200 ms RTT in some cases. So what? Get over it.

You're missing a zero in that RTT for users in places like Asia if your server is anywhere in the west. (It's actually somewhat revealing when someone throws out a number like this without any qualification; what exactly made you conclude 200ms is the magic number?)

> Optimize your website to load in fewer round-trips. TCP congestion control adapts well enough to any latency. RTT only really matters in gaming and VoIP.

You don't need a very big imagination to think about cases where RTT will have significant impacts e.g. in the event you need to issue multiple sequential requests that are dependent on one another. These are unavoidable and occur often in more than just websites, but anything that e.g. uses HTTP as an API (a very simple one is something like recursively downloading dependencies.)

This comes across as a classic "I don't actually understand the problem domain very well at all, but get off my lawn" answer to the problem.

Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea

#170

Post by ipaddr »

ehutch79 wrote: post #162
floatboth wrote: post #155

Earlier quoted context omitted.

For regular public web pages , serving the actual fucking page should not be more expensive than serving the captcha page! What the hell is a "bad actor" in relation to GET requests to a public page ? To a public page , all actors should be inherently neutral.

There's a lot of potential side effects. Not every GET request retrieves a static asset. A list view with filters for instance. Either way, you could be dumping any arbitrary data along with a request. Or just try fuzzing parameters. some pages might be poorly done graphQL endpoints, and your might find your db tied up. There are MANY ways a legit a get request can cause issues, let alone someone with bad intentions.

All users are hostile users and all users are preferred users. Define what your system will allow through rate limits and caching. Assume users would destory your site if given the chance because they will. If you are exposing private data through graphgl config it or drop the private data or drop graphgl and user a backend.
Post reply on HN