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

271–280 of 294 posts

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

#271

Post by danShumway »

derefr wrote: post #182
anothergram wrote: post #160

Earlier quoted context omitted.

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.

Sometimes serving 429s/403s to unauthed users is already costing you too much in egress bandwidth bills. That’s one of Cloudflare’s main propositions: stop that “idiot bot that will never get what it wants, but keeps requesting it anyway” traffic outside your network. (Note: not the same as a DoS! Usually not intentional, and usually not actually bringing your infra down. Just costing you money, while not making you…

Is there a reason Cloudflare can't send a 429/403 in that situation if you're already using it as a middleperson?

It seems like responding to a bot and responding to an unpaid accidental request would take the same amount of energy from Cloudflare. The only difference is that a repetitive unpaid request is probably easier to detect.

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

#272

Post by floatboth »

djoldman wrote: post #166
floatboth wrote: post #154

Earlier quoted context omitted.

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?

Token manufacturers are the CAs for their own tokens, Cloudflare would know these CA public keys.

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

#273

Post by floatboth »

ehutch79 wrote: post #175
ipaddr wrote: post #170

Earlier quoted context omitted.

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…

Cloudflare gets you very paranoid, overly aggressive, user-hostile protections by default – and people just take the defaults even if they use it with STATIC HOSTING LIKE GITHUB PAGES!

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

#274

Post by BillinghamJ »

danShumway wrote: post #65

Complete aside, but I'm still not certain I understand the technical details of why Cloudflare can't uniquely identify users. I thought I knew how hardware keys worked, but apparently I don't. If the key being shared is embedded in the device, even in a secure enclave or something, then my understanding was that would open the door for key extraction. If the key is unique per-device, then that's not a problem. But if…

Re uniqueness - given how FIDO2 tends to work, I'd also expect it to be RP ID (ie domain) scoped. Possible that's not true for the attestation/registration side though?

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

#275

Post by TimWolla »

ignoramous wrote: post #242
TimWolla wrote: post #216

Earlier quoted context omitted.

> For instance, Yubi Key 5 supports up to 25 keys This is for resident keys. A YubiKey 5 supports an infinite number of non-resident WebAuthn keys, because the returned key handle will simply be the private key encrypted with a master key stored on the YubiKey. For authentication the service will send the stored key handle back to the YubiKey which then can decrypt it and use the decrypted private key to sign the cha…

TIL. Envelope encryption. Neat. Can WebAuthn keys be (made) a resident key? If so, is that preferred instead? Conversely, what use case is there for resident keys in context of WebAuthn? For example, if there are multiple master keys, can I switch between them per browser / website (assuming the master key itself is a resident key and not burnt into the element)? Thanks.

The WebAuthn API can register a resident key on the YubiKey. This will basically store the username, private key and domain on the YubiKey. The website then can later request authentication based off a resident key. This will cause your web browser to query the YubiKey for resident keys of the website. You then can select the resident key with the correct username and will be logged in based on strong cryptography without needing to enter your password or username. Depending on your YubiKey configuration you might need to enter your YubiKey pin for this to work. See the screenshot in this comment on a GitHub issue: https://github.com/keepassxreboot/keepassxc/issues/3560#issu...

The website will need to support this of course. Also the amount of storage available for resident keys on the YubiKey is limited.

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

#276

Post by md_ »

dane-pgp wrote: post #234
md_ wrote: post #81

Earlier quoted context omitted.

https://fidoalliance.org/fido-technotes-the-truth-about-atte... explains this pretty well. Basically: * Attestation keys are not unique per authenticator; they're shared among batches of authenticators. * If you extract the batch's attestation key, you can imitate authenticators from that batch. That doesn't mean you can authenticate as a registered authenticator, of course; it just means you can pretend to be a "Yub…

> they can always choose to distrust batches known to be compromised. Which effectively means bricking the devices of 9999 innocent users each time. Why are we creating a world where users will be told they can't visit a website or access their account any more because they didn't spend enough money on a hardware DRM device which tries to hide a key from them?

Hmm. I'm of two minds about this.

Vanguard restricts (or used to) trusted keys to those made by Yubico. This annoys me, given they let me use any phone number. So this suggests (as you seem to be arguing) that attestation is an attractive nuisance—when you can't tell whether a phone number is with a trustworthy or untrustworthy exchange, teleco, or VOIP service, you just have no choice but to trust it. But when you can enforce attestation, some Vanguard employee with a Yubico Certified Security Engineer certificate (I made that up) decides to restrict us to Yubico's keys.

On the other hand, FIDO aims to also support enterprise usage, and I think it'd be a nonstarter to say that enterprises shouldn't be able to restrict you to officially issued authenticators—and without remote attestation, they'd have to do more cumbersome steps like handling enrollment centrally (and then shipping enrolled authenticators to users), which, in a distributed workforce, sucks.

So attestation fills a need, and I think we just have to hope it's not widely used or abused.

Is Cloudflare's usage an abuse? Eh, I don't know. It's an interesting experiment.

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

#277

Post by zo1 »

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?

We're solving the wrong thing here. We should be going directly to the source: The mis-behaving (for whatever reason) IP and the ISP that owns it. We should be fostering an ecosystem that solves that problem, not one that results in a CloudFlare popping up. Which proverbially just throws spaghetti (money, technical-expertise and infrastructure) at the problem, and then using that accumulated power to shape (or manipulate) the web to its liking, and to kick-off anyone it doesn't like off it, of course.

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

#278

Post by pas »

NaturalPhallacy wrote: post #266
fierro wrote: post #189

Earlier quoted context omitted.

why is it assumed the web ought to be crawleable?

So that we can find things on it without prior knowledge.

You already get a lot of defaults from your vendor (OS, device, browser). Why couldn't these vendors maintain a bigger list of default entrypoints for the web? They already do for "apps".

Plus there is already an endless sea of walled stuff (paywall, "create an account and login" wall, "fill in your address/ZIP code and we'll give you the best price" wall, government filtering wall).

I'm not saying it's great, or it would be great, but currently having 1 (or maybe 1-and-half) search engines is also very far from ideal.

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

#279

Post by dane-pgp »

md_ wrote: post #276
dane-pgp wrote: post #234

Earlier quoted context omitted.

> they can always choose to distrust batches known to be compromised. Which effectively means bricking the devices of 9999 innocent users each time. Why are we creating a world where users will be told they can't visit a website or access their account any more because they didn't spend enough money on a hardware DRM device which tries to hide a key from them?

Hmm. I'm of two minds about this. Vanguard restricts (or used to) trusted keys to those made by Yubico. This annoys me, given they let me use any phone number. So this suggests (as you seem to be arguing) that attestation is an attractive nuisance—when you can't tell whether a phone number is with a trustworthy or untrustworthy exchange, teleco, or VOIP service, you just have no choice but to trust it. But when you c…

> FIDO aims to also support enterprise usage

It seems to me that this use case is completely at odds with the general use cases we expect when people browse the web.

In the enterprise, society accepts the idea that someone's employer knows their name, their address, their bank details, and even everything they browse on their company-issued computer. Whether that's good or bad, it's not a model that FIDO should be trying to support.

This reminds me of the controversy around TLS 1.3 allowing forward secrecy.[0] If companies want to make their own alternative to FIDO which has DRM and user tracking, to control access to their intranets, that's fine, but we shouldn't have allowed FIDO to become a Trojan Horse (or Trojan Dog?) to sneak this anti-feature into the general web.

[0] https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-s...

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

#280

Post by derefr »

danShumway wrote: post #271
derefr wrote: post #182

Earlier quoted context omitted.

Sometimes serving 429s/403s to unauthed users is already costing you too much in egress bandwidth bills. That’s one of Cloudflare’s main propositions: stop that “idiot bot that will never get what it wants, but keeps requesting it anyway” traffic outside your network. (Note: not the same as a DoS! Usually not intentional, and usually not actually bringing your infra down. Just costing you money, while not making you…

Is there a reason Cloudflare can't send a 429/403 in that situation if you're already using it as a middleperson? It seems like responding to a bot and responding to an unpaid accidental request would take the same amount of energy from Cloudflare. The only difference is that a repetitive unpaid request is probably easier to detect.

Oh, they totally can, but you have to get Cloudflare to be your auth gateway (using e.g. https://www.cloudflare.com/en-ca/teams/access/ .) Usually companies who have this problem already have an auth system in place and well-ossified (i.e. with customers who’ve burned assumptions about it into software like mobile apps, that can’t be “forced” to update.) So it’s pretty hard to do a migration.
Post reply on HN