Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Pre-Registration Discovery #503
Greetings, WebAuthN folks.
Facebook has now had U2F available as a second-factor authentication technology for not quite six months. I'd like to share some challenges we have and are encountering with our deployment in hopes that these might be addressed by the WebAuthN work.
Specifically, I want to raise the issue that the lack of pre-registration discovery presents a major obstacle to both reach and usability.
In terms of reach, only a small number of people actually have U2F devices. We would like to be able to enroll as many active users of these devices as possible, and expect that most people who are both U2F and Facebook users would like to use their devices with us. And yet, many people who use U2F don't know that Facebook supports it. If this is the case for the highly technical segment of people using U2F today at one of the world's most well-known websites, imagine how difficult this will be in the tail of services that may support Web AuthN.
It would be very helpful if, the first time a Web AuthN capability is used in a user agent, the individual was presented with the option to advertise that they have and use this capability, so that other services that support it can promote it to the user or prompt them to set it up.
A closely related problem is that giving good instructions to an individual registering their authenticator is very difficult with no information about how that authenticator is exposed or what ceremony is necessary to use it. Facebook currently generically instructs people to insert their authenticator into the USB port of their computer, but those instructions are flatly wrong for a BTLE attached device, or a U2F capability integrated into the chipset of their device but exposed over the USB bus. Some of this information appears to become available as selectors in the WebAuthN API after an authenticator has already been registered, but not at the most critical time - when the person is first setting it up.
Again, it would be nice if there was an opt-in possible to let people advertise that they have an authenticator, and its basic capabilities, so that services which support it can present an appropriate registration experience.
I think this is mainly relevant in the case of roaming authenticators as bound authenticator would always be responsive (to a create call).
But even without actively advertising the support for access to a roaming Authenticator on the platform to the RP JS Code, the Browser could remember that it has seen a roaming Authenticator before and could ask the user whether to use/insert it or to say no authenticator available (when encountering a create call for a WebAuthn credential).
So this could potentially be addressed by implementation guidance (even without an API change).
Even for a bound authenticator, how do I know if a given person arriving at my service in a browser actually has an authenticator available? My request is that: 1) Be able to determine if a given person has an authenticator available they want to use, so that we can promote the setup flow non-intrusively. (e.g. put an install banner across the top of the screen) I don't want to just randomly call create credential and trigger some kind of modal experience if that's not what the person is in the context of doing at the time. People very rarely visit their security settings without some kind of soft prompting. 2) Be able, when the user is in the context of setting up their authenticator and starting the registration process, to understand enough about the characteristics to present appropriate instructions.…
On Fri, Jul 7, 2017 at 9:22 AM Rolf Lindemann ***@***.***> wrote: I think this is mainly relevant in the case of roaming authenticators as bound authenticator would always be responsive (to a create call). But even without actively advertising the support for access to a roaming Authenticator on the platform to the RP JS Code, the Browser could remember that it has seen a roaming Authenticator before and could ask the user whether to use/insert it or to say no authenticator available (when encountering a create call for a WebAuthn credential). So this could potentially be addressed by implementation guidance (even without an API change). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#503 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACFbcBXClZCllMY0NZSKc2kAWuvOBi_1ks5sLls9gaJpZM4OQW-f> .
To add to @equalsJeffH's point, we saw similar issues at MS when we were talking to our partners at different websites. The amount of devices available to perform the authentication requirements are such a small number compared to the backdrop of the web. Especially since web devs are trying to write once and work everywhere, they have to have a way for figure out if the user's device is capable. Also, webauthn covers a bigger device range than U2F. The issue becomes more complicated.
Since Github, apparently, does not automatically include comments submitted through firstname.lastname@example.org, I was requested to post them here for the record. Sorry for the duplicate e-mail that goes out on this.
I'm not going to discuss the merits/demerits of "advertising" that I have a FIDO U2F Authenticator (its bad enough that business models are so skewed already to profit on users' private information without users
What prevents the world's most well-known websites that support FIDO from displaying, on their home-page or login page, that they support strong-authentication? And, making it the first choice for sign-ups? Let's see how many well-known sites advertise that they use strong-authentication to protect users on their home-page?
https://www.facebook.com/ - Nope; only has password.
Now, lets see what an obscure small business that builds an open-source FIDO Certified server does with a couple of FIDO-enabled applications it builds:
Brad, I'm not trying to ridicule your efforts at helping people use strong-authentication; I applaud your efforts - and that of all these companies who have invested time and money to integrate FIDO into their sites. But, that's just NOT enough!!
Its not enough to claim on blogs, PR and mailing lists that a site supports strong-authentication for users. You need to "shove it into their faces" that this is what you have now, and this is for their benefit.
While I recognize that the business models of these companies depend very much on making the sign-up and login process as painless as possible, I can only imagine the amount of money that is wasted in protecting these sites from constant attacks because of passwords. I don't have the data, but I am willing to make a small wager that FIDO-enabled sites that do not make strong-authentication the first and default choice for sign-ups and logins, are reducing their overall profits by not educating people about FIDO when they first land on these home pages.
IMHO, it is not enough to silently protect users - it is imperative you educate them first. Its the same old story about "giving someone a fish to eat, or teaching them how to fish".
Keep up the good work though; every little bit helps.
@devd the PR is structured in a way to give flexibility to the browser vendors as to how they want the experience to look like. Browsers can decide whether to give a prompt or add something in setting or other UX when they give the information to the RP. There are concerns that without the permission prompt, it'd be fingerprinting. That's why the PR mentions the permission prompt.