Re: [webauthn] Can RPs assume that `InvalidStateError` for `create()` means an excludeCredentials match? (#1566)

My point is that you can't have your cake and eat it too, Lucas.

FIDO is a security technology - not a convenience technology. 
Consequently, you should begin your deployment with a focus on what 
security you want for your environment and then think of the UX.

The way I see it, you have the following choices for security:

* Strictest - ALWAYS requires UV and only accepts specific AAGUIDs;
* Strict  - ALWAYS requires UV from any AAGUID;
* Reasonable - ONLY accepts specific AAGUIDs;
* Minimum - ANY AAGUID that supports UP;
* "You've got to be kidding me" - What we have currently.

What we (at StrongKey) are trying to get the world to adopt is 
"Minimum". I still can't believe that 7 years after joining the FIDO 
Alliance, and nearly 6 years after putting out our first open-source 
FIDO Certified server, we're nowhere near that! Even now, I run into 
technical people who've never heard of FIDO (or PKI, the progenitor of 
passwordless authentication).

What's galling is that companies like Google, Facebook and Twitter (and 
many more - you know who you are) - which support "Minimum" right now - 
could educate 2B+ people overnight and raise the security bar if they 
chose to; but they won't do it, putting profits ahead of doing what's 
right for the entire ecosystem.

My recommendation is to focus on what security you want first, and then 
design your UX for what meets that policy. Trying to find the perfect 
solution continues to leave the world in a bloody mess (just look at 
what SolarWinds + VMware has wrought recently).

Arshad Noor
StrongKey

On 2/19/21 4:32 PM, Lucas Garron via GitHub wrote:
>> if there is no intent to implement FIDO for its raison d'etre, why 
>> bother implementing it at all?
> 
> I’m not sure I follow. We’re implemented “trusted devices” as described 
> in the spec (see my link above).
> 
> The trusted device concept works regardless of whether a user has 
> additional 2FA options, and we want to offer something that is both 
> safer and more convenient than what the vast majority of users are 
> currently using.
> 
> Industry-wide adoption numbers for 2FA are low, and I think that gating 
> trusted device functionality behind the complexity of normal 2FA is 
> counter to the goals and the spirit of the spec.
> 
> (That said, I think it would be great to get to the point where WebAuthn 
> can be used so commonly that we can raise the bar for non-WebAuthn login 
> as well.)
>

Received on Saturday, 20 February 2021 14:36:17 UTC