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

171–180 of 294 posts

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

#171

Post by D-Nice »

ehutch79 wrote: post #135
grishka wrote: post #132

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.

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?

Why is every and any TOR and sometimes VPN user deemed a DoS attack... it discriminates against users who value privacy by forcing hCaptcha on them by default. Worst of all... it could be a de-anonymization attack as well, hence why I as a regular TOR user, just exit the page immediately when that happens.

For any of my pages that do happen to use Cloudflare, I am luckily able to disable this discrimination in the CP so kudos for that at least, but terrible defaults imo.

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

#172

Post by AtNightWeCode »

There are a lot services in Sweden that requires that you provide a real authentication by using something called BankId. Basically a personal digital id. This is the way to go. 100% secure validated users. If there was a function added to make the users anonymous to third party services it would be great.

I work with Cloudflare sites and it is clear that thier current enterprise offerings are hard to tweak to solve attacks without spamming the users with captchas. The captchas are already too complicated for the average user so it is mostly turned off even though it has other consequences. I have to look into this new thing though.

As much as I like the idea of an open Internet to be used by anyone from anywhere. It does simply not work today for a lot of enterprises.

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

#173

Post by ehutch79 »

stickfigure wrote: post #168
ehutch79 wrote: post #150

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…

But wouldn't the response the mockup gets only work for that page, not something they could pass through?

If any page can request any other pages response that'd make the whole system pointless

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

#174

Post by sroussey »

anothergram wrote: post #160
ve55 wrote: 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.

Once logged in perhaps. But credential stuffing is a thing.

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

#175

Post by ehutch79 »

ipaddr wrote: post #170
ehutch79 wrote: post #162

Earlier quoted context omitted.

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.

I 100% agree you should be looking at all incoming traffic as hostile or at least potentially hostile. The other comments are contending that there's nothing a hostile user could do to a 'public' page.

One of the things using cloudflare gets you is all those protections without having to know how to do them yourself. Which a lot of the developers don't know how to do.

There's also something to be said for catching a lot of this at the network layer on a cluster of machines that can handle any incoming traffic that your one poor neglected vm can't.

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

#176

Post by sroussey »

D-Nice wrote: post #171
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?

Why is every and any TOR and sometimes VPN user deemed a DoS attack... it discriminates against users who value privacy by forcing hCaptcha on them by default. Worst of all... it could be a de-anonymization attack as well, hence why I as a regular TOR user, just exit the page immediately when that happens. For any of my pages that do happen to use Cloudflare, I am luckily able to disable this discrimination in the CP…

From experience, traffic via Tor was always 99%+ fraud.

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

#177

Post by ehutch79 »

D-Nice wrote: post #171
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?

Why is every and any TOR and sometimes VPN user deemed a DoS attack... it discriminates against users who value privacy by forcing hCaptcha on them by default. Worst of all... it could be a de-anonymization attack as well, hence why I as a regular TOR user, just exit the page immediately when that happens. For any of my pages that do happen to use Cloudflare, I am luckily able to disable this discrimination in the CP…

Because that's a not insignificant portion of traffic they see from tor and vpns?

tor has some absolutely valid and import use cases, but what percent of tor exit traffic is actually someone trying to keep their traffic anonymous from the eyes of an oppressive regime, and what percent are script kiddies, or someone hiding torrenting from their isp?

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

#178

Post by grishka »

aseipp wrote: post #169
grishka wrote: post #143

Earlier quoted context omitted.

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…

> 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 that cancels out because RTT is a measure of how long it takes for a signal to travel back and forth. You then add some time on top of that to account for buffering and processing in the various equipment along the way.

> 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.)

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.

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

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

#179

Post by ehutch79 »

gsich wrote: post #167
ehutch79 wrote: post #161

Earlier quoted context omitted.

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.

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 sales people taveling to a client. or on site inspections of a manufacturer in a warehouse that's mostly metal and has bad wifi.

Post reply on HN