A very important addition to the article is that you don't have to have Ryzen for this, just a motherboard that has a good chipset for handling 128 or 256 USB ids simultaneously. I speak from experience.
Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
281–290 of 294 posts
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#282Earlier quoted context omitted.
Yes, they absolutely are. Hell just getting a few random bots scraping stuck in a loop or being overly aggressive on your site is enough to double your bill. So yeah it's 100% required.
Did we collectively forget rate limiting exists or something? One bot that's just stuck on a loop or being overly aggressive is going to have one IP.
That is fair but instead of bothering to set that up I can just sign up for a free service in a hour once and just never worry about it.
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#283How does this so called 'CAPTCHA replacement' idea compare to Sign In With Apple? which also does not use any CAPTCHAs and aims to prevent bot sign ups.
Apple Sign-In is just an OpenID federated login; these don't inherently provide any anti-automation or rate limiting; they just push the problem to the Identity Provider. IdPs like Apple/Google/Microsoft might do a fine job of limiting you to "one account per $unit-of-hardware"; Apple in particular can do this via iOS attestation. But then you're limited to either their heuristics (in the case of MSFT/Google) or thei…
Maybe. I would have to read the FIDO group’s discussions on this to be confident in my opinion. :)
I personally enjoy the ability to use my employer-provided authenticators on my personal accounts. I think this is both convenient (only one thing to carry) and helps adoption (I got a key “for free”). So maybe enterprise use is a Trojan Horse to promote consumer adoption?
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#284Earlier quoted context omitted.
I almost never see a captcha. On a static fiber IP - 1GB. Use chrome. Not sure if that matters.
> Use chrome. That's why. Try using Firefox without being logged in to Google and with an ad blocker - you really won't like it.
I’m using Firefox, and are often doing stuff in Private Mode, where I’m not logged into Google, and am using uBlock, and Firefox’s strict tracking protection. CloudFlare and Google doesn’t serve me any CAPTCHAs.
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#285Earlier quoted context omitted.
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.
This is exactly the case.
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#286Earlier quoted context omitted.
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 tr…
Let me give you a little more of a fleshed-out use-case, then, as well as some alternative designs that come to mind.
Let's imagine I'm a consumer bank. I want the following features:
* I ship users a FIDO key when they sign up for an account.
* Users can register additional keys they bought or already have, and can use my key elsewhere.
* I consider malware on the user's computer to be in the scope of my threat model, and so I want all risky transactions (like transferring money) to come with a secure test of user presence.
I believe that the above three constraints are sufficient to motivate the current design. Why?
Well, let's say we do the obvious and just eliminate attestation. If the design otherwise remains unchanged, there's nothing to prevent clever malware from piggybacking a legitimate user presence tap to add a malicious, software-only authenticator to the user's account, which can then approve future transactions.[1]
Currently, however, I can simply require that authenticators all be non-self-signed, restricting to those that come with real hardware-backed security.
So now I have a few options. I can:
a) Disallow enrolling new authenticators. I think this is the worst option, because it means that the FIDO ecosystem would basically revert to (at worst) "an authenticator per relying party", which is expressly something it aims to avoid. (Think, keyrings full of USB fobs!)
b) Declare malware out of scope. I find this unsatisfying, since it suggests we might as well just replace FIDO with USB keys with X509 client certs, but see my footnote [1]--maybe at the limit these are equivalent?
c) Do what the FIDO Alliance seem to have done: create batch attestation, but discourage RPs from using it spuriously.
I think (c) is fairly reasonable, but as I said, I do find the entire malware argument sort of unsatisfying in a way, so, shrug.
[1] Arguably, if this is an attack you are concerned about, malware can also just piggyback presence to directly trigger transfers and other abuse, of course, so maybe this argument is a weak one? But I think an RP might reasonably want to say that "malware can do anything malicious within 10 seconds of a tap on your key, but if you think someone might have hacked your account, just remove your key and call customer support." If malware can add new software-only authenticators, it violates this functionality.
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#287Earlier quoted context omitted.
- Yes. - To my (limited) knowledge, yes, you are right that keys will get more unique over time. That's a very good point. Keys are not rotated nor (generally) are they rotatable; they are usually read-only. If you are using a very old FIDO device and worried it has too much entropy now--like, if it's a "rare" or "vintage" device!--then you should buy a new one, I guess? (I honestly have not thought about your second…
Manufacturers don't necessarily have to rotate the keys on older devices; they could rotate the keys on newer devices such that it's difficult to reliably tell what batch/generation a newer device is from, because it could be using a newer or older key. Such behavior would require some way of revoking old keys from newer devices to prevent a situation where a compromised and blacklisted old key is selected and causes…
I don't totally follow. The key is baked into each device, so if you sold a mix of devices where some had the old key and some the new, revocation of the old key would brick the new devices with that old key.
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#288Earlier quoted context omitted.
Apple Sign-In is just an OpenID federated login; these don't inherently provide any anti-automation or rate limiting; they just push the problem to the Identity Provider. IdPs like Apple/Google/Microsoft might do a fine job of limiting you to "one account per $unit-of-hardware"; Apple in particular can do this via iOS attestation. But then you're limited to either their heuristics (in the case of MSFT/Google) or thei…
Maybe. I would have to read the FIDO group’s discussions on this to be confident in my opinion. :) I personally enjoy the ability to use my employer-provided authenticators on my personal accounts. I think this is both convenient (only one thing to carry) and helps adoption (I got a key “for free”). So maybe enterprise use is a Trojan Horse to promote consumer adoption?
Hmm. I replied to the wrong post.
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#289Earlier quoted context omitted.
> 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 tr…
Let me give you a little more of a fleshed-out use-case, then, as well as some alternative designs that come to mind. Let's imagine I'm a consumer bank. I want the following features: * I ship users a FIDO key when they sign up for an account. * Users can register additional keys they bought or already have, and can use my key elsewhere. * I consider malware on the user's computer to be in the scope of my threat mode…
> restricting to those that come with real hardware-backed security.
And presumably RPs in practice achieve this by subscribing to a list of key updates managed by the FIDO Alliance themselves. That seems like it puts a lot of control over the web into the hands of a group whose incentives may not be the same as those of the average web user.
As a point of comparison, my impression is that it's been quite difficult to get all Certificate Authorities to correctly follow the CA/Browser Forum rules, and to tighten those rules. That forum at least tries to balance the wishes of User Agents against those of the entities selling (access to) the keys, which I'm not sure if FIDO will achieve.
> malware can do anything malicious within 10 seconds of a tap on your key
If this is the security situation that FIDO aims to create, then I'm not sure if requiring a whitelisted hardware device adds anything, relative to allowing self-signed software-only authenticators, other than security theatre and a single point of failure (namely the whitelist itself).
Re: Cloudflare’s CAPTCHA replacement with FIDO2/WebAuthn is a bad idea
#290Earlier quoted context omitted.
Let me give you a little more of a fleshed-out use-case, then, as well as some alternative designs that come to mind. Let's imagine I'm a consumer bank. I want the following features: * I ship users a FIDO key when they sign up for an account. * Users can register additional keys they bought or already have, and can use my key elsewhere. * I consider malware on the user's computer to be in the scope of my threat mode…
> restricting to those that come with real hardware-backed security. And presumably RPs in practice achieve this by subscribing to a list of key updates managed by the FIDO Alliance themselves. That seems like it puts a lot of control over the web into the hands of a group whose incentives may not be the same as those of the average web user. As a point of comparison, my impression is that it's been quite difficult t…
> And presumably RPs in practice achieve this by subscribing to a list of key updates managed by the FIDO Alliance themselves. That seems like it puts a lot of control over the web into the hands of a group whose incentives may not be the same as those of the average web user.
I'm not aware of the FIDO Alliance doing this today. I guess anyone could create such a list, but while I think your concern is valid, it has not (yet) played out that way, so I don't think you can claim it's inevitable.
Anyway, I laid out what I believe are the reasonable alternatives. I think you're taking the position that local malware is already sufficiently powerful that it's not meaningful to restrict adding new authenticators?
I entertained this as well, and I think there's validity to it--but I do think it's reasonable for an RP to say, "If you unplug your FIDO key, the attacker is thwarted", which is not something that remains true if you allow self-signed authenticators.