Live data from Hacker News

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

herrjemand.medium.com

191–200 of 294 posts

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

#191
post #12

Cloudflare is both a great thing and a terrible thing that has happened to the internet in recent years. Great in that they have a fantastic UI to add your site in, basically shielding the average user from attacks. Bad from a standpoint of that now only Google, Bing, and maybe other big search engines have the capabilities to actually crawl the internet now. I don't see us getting a massive innovation in search on t…

This feature is enabled at the behest of the site owner. I feel like site owners and operators should decide who gets to visit their site. Am I missing something obvious here?

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

#192

I hate this new web where you're automatically assumed to be some malicious actor only because you don't accept cookies and strange third party code and then have to jump through hoops to show that you're not some evil bot. To be honest, if a website immediately throws some Cloudflare anti-DDoS thing in my face I don't even bother anymore.

We all do. Everybody who's ever worked in security hates that even the tiniest hole in your security will be squeezed through. If you don't distrust every single packet, then sooner or later one of those packets is going to destroy you.

It's basically the same both ways. You don't trust them with your private info. They don't trust you, either. The easiest way is, indeed, to just call the whole thing off.

Everybody would love an alternative that lets more get done with less trust. Sometimes they find them, for limited cases. But nobody's solved it for the general case.

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

#193
post #185

Cloudflare captchas in particular, and any checks and roadblocks to see something publicly available in general, are terrible, period. It doesn't matter which form they take. Every time you see one you feel like a second-class citizen and get reminded that the internet is no longer what it used to be. I personally simply close the tab when I see a cloudflare "one more step" page.

what? Have you ever dealt with a DDoS attack and the consequences on your availability and infra health?

Of course from the perspective of the website operator it’s great, but from the perspective of the user it’s frustrating.

I’m not sure whether this is true, but it seems like with Firefox I get these captchas much more often than with Chrome. Sometimes they’re so difficult to solve it really takes a minute or two to do so, and it’s incredibly disturbing / an unfriendly interaction.

Surely there must be a better way to deal with this? Why do I have to keep proving again and again and again to Cloudflare I am, in fact, a person?

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

#194
post #167

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. Because this implies that.

No it doesn't. at all. Page load speeds by themselves can be painful. Open devtools and have your browser throttle to poor 3g speeds. Try browsing around. even well optimized sites. Now try uploading a couple dozen files through an api. This is legit what some users deal with. In New York state even, you don't need to go that far to find poor connectivity. Even if all your users have awesome home connections, think s…

If you're on 3G I would expect sites to load in a similarly bad way with or without an extra most of 200ms of RTT.

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

#195
post #153

The way I'd put it is that Cloudflare's suggested implementation may have its issues, but the general idea of trying to verify that someone is a human and then providing this verification to services in a way that is 1) anonymous and 2) cross-compatible with other services, is the correct way to go about things (or at least has some very appealing features). I hope that we have something in the future that does this…

Alternatively, if services demand a fee then there is no need for human verification. Instead of trying to solve anonymous human verification we can as well make micro-payment an option.

I really hate it when I'm trying to spend money at a company and get hit with a captcha box right as I click "checkout". I could see it for selling scarce items like concert tickets, but in general it's very insulting, annoying, and off-putting to me.

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

#196

Earlier quoted context omitted.

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…

No. Ignorance is a big problem. What makes Security Keys work well isn't that they are "rarely called for" but almost the opposite, they're so easy that you can add them with little friction all over the place. Tapping to sign into a remote server over SSH is no problem, it's scarcely more effort than thumping "enter" on the command is.

What the user is doing is not security sensitive. They are, in fact, themselves, and that's all the Security Key is confirming. "Yup, still me".

One of the easy ways fools trip themselves up here is that they think this is identifying information. But it isn't. "Yup, still me" doesn't identify anyone. The identity was already known to your interlocutor, which is why "Yup, still me" is enough.

And that's what's so clever about the FIDO design. A Security Key has no idea who it "is", it just knows it's still the same as before. If you're already authenticated as Jim Smith, you can enroll a security key "Yup, still me" -> the Relying Party stores the information, and then you can later sign in using it to verify your identity, "I'm Jim Smith". "Is this still you Jim Smith?" "Yup, still me".

So that's why this doesn't help bad guys. "Are you still er... you?" "Yup, still me". Completely useless. Of course you are, that doesn't help them at all.

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

#197
post #169

Earlier quoted context omitted.

> 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…

> You're missing a zero in that RTT for users in places like Asia if your server is anywhere in the west. Well, it does say 130 ms in here: https://www.quora.com/How-long-would-it-take-for-light-to-fl... And that's around the planet, to go around and end up at the same spot. In practice, with sanely-configured routes, your packets should never need to traverse more than half that distance. So, divide it by 2, then th…

Of course, light doesn't travel at vacuum speed in fiber, it travels a bit slower, but it also bounces around the cable, so ends up traveling a significantly longer distance. Multiply by around 1.5 for more real world numbers (copper is similar), just measuring raw distance.

And switching adds significant delay, especially when you get out to the edge.

> If you mean REST API requests, the kind that trigger some code to dynamically generate a response, how would a CDN solution like cloudflare help? The request still needs to get to the server and the response still needs to come back, all the way, because that's where that code runs. CDNs only really work for cacheable static content, don't they? I mean it's in the name.

For a simple example, imagine assets that are dynamically loaded based on feature detection in JS. All of the assets (js included) can be cached on the cdn.

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

#198
post #169

Earlier quoted context omitted.

> 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…

> You're missing a zero in that RTT for users in places like Asia if your server is anywhere in the west. Well, it does say 130 ms in here: https://www.quora.com/How-long-would-it-take-for-light-to-fl... And that's around the planet, to go around and end up at the same spot. In practice, with sanely-configured routes, your packets should never need to traverse more than half that distance. So, divide it by 2, then th…

> Well, it does say 130 ms in here.

If you have a fiber backed, all-switched network with no routing, buffers, congestions, or detours, you may get that value, if you're lucky.

Pinging tty.sdf.org which is a direct access shell service in USA from somewhere between Europe and Asia, from an academic network backbone roundtrips in ~190ms. I'm traversing a little less than half a globe with the whole journey. In your terms, it should be around ~60ms, but it's not.

> If you mean REST API requests, the kind that trigger some code to dynamically generate a response, how would a CDN solution like cloudflare help?

By using Cloudflare workers, so your code is also distributed around the globe?

> CDNs only really work for cacheable static content, don't they? I mean it's in the name.

JS files are also static content. Unless you don't use code distribution like Cloudflare workers, using a simple CDN can cache 90% of your site if not more. CSS, images, JS, HTML, you name it.

> A blog or a news website certainly doesn't need a CDN.

Actually, CDN is the most basic optimization for distributing heavy assets like videos and images, which news websites use way more than text. Why not use a CDN?

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

#199
post #169

Earlier quoted context omitted.

> 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…

> You're missing a zero in that RTT for users in places like Asia if your server is anywhere in the west. Well, it does say 130 ms in here: https://www.quora.com/How-long-would-it-take-for-light-to-fl... And that's around the planet, to go around and end up at the same spot. In practice, with sanely-configured routes, your packets should never need to traverse more than half that distance. So, divide it by 2, then th…

There's no need to guess based on the speed of light. Test it yourself:

https://www.cloudping.info

For me, the highest was 310ms round trip to Singapore, so higher than your estimate but not too bad.

But this is completely beside the point. As far as I know, if you're using a CDN effectively (i.e. a large proportion of requests are hitting cache), it should be cheaper than having all requests hit your server, not more expensive. So even if you don't "need" a CDN, you might want one. This is orthogonal to the issue of bot traffic, which exists whether or not you use a CDN. If you want to use a CDN but don't mind the costs of bot traffic, you can configure CloudFlare to not show the CAPTCHAs, or use a different CDN.

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

#200

Earlier quoted context omitted.

> You're missing a zero in that RTT for users in places like Asia if your server is anywhere in the west. Well, it does say 130 ms in here: https://www.quora.com/How-long-would-it-take-for-light-to-fl... And that's around the planet, to go around and end up at the same spot. In practice, with sanely-configured routes, your packets should never need to traverse more than half that distance. So, divide it by 2, then th…

> Well, it does say 130 ms in here. If you have a fiber backed, all-switched network with no routing, buffers, congestions, or detours, you may get that value, if you're lucky . Pinging tty.sdf.org which is a direct access shell service in USA from somewhere between Europe and Asia, from an academic network backbone roundtrips in ~190ms. I'm traversing a little less than half a globe with the whole journey. In your t…

> Pinging tty.sdf.org which is a direct access shell service in USA from somewhere between Europe and Asia, from an academic network backbone roundtrips in ~190ms.

Actually I get around 200 from Russia which is also "somewhere between Europe and Asia":

   round-trip min/avg/max/stddev = 196.504/197.581/199.833/1.360 ms
> By using Cloudflare workers, so your code is also distributed around the globe?

Great, let's give that company even more control. That's sure gonna end well.

> CSS, images, JS, HTML, you name it.

It all gets loaded once and then cached in the browser. The initial load takes long regardless of whether there's a CDN. Oh, and many websites also use stuff from like 10 different domains, which doesn't help this either.

And, it doesn't matter whether a JS file loads in 50 ms or 300 ms, if it then takes 5 seconds to parse and start running.

> Actually, CDN is the most basic optimization for distributing heavy assets like videos and images, which news websites use way more than text. Why not use a CDN?

So put them on a separate domain and serve that from a CDN if you really care whether that stock photo no one notices loads in 500 ms instead of 2000. That doesn't explain much why anyone would put their main domain behind cloudflare.

Post reply on HN