New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pre-Registration Discovery #503

Closed
hillbrad opened this Issue Jul 7, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@hillbrad

hillbrad commented Jul 7, 2017

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.

@rlin1

This comment has been minimized.

Contributor

rlin1 commented Jul 7, 2017

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

@hillbrad

This comment has been minimized.

hillbrad commented Jul 7, 2017

@equalsJeffH

This comment has been minimized.

Contributor

equalsJeffH commented Jul 7, 2017

IIUC, there is work-in-progress that may address your needs, please see issues #345 and #349, and PR #379 -- does that help?

@AngeloKai

This comment has been minimized.

Contributor

AngeloKai commented Jul 7, 2017

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.

@arshadnoor

This comment has been minimized.

arshadnoor commented Jul 7, 2017

Since Github, apparently, does not automatically include comments submitted through public-webauthn@w3.org, I was requested to post them here for the record. Sorry for the duplicate e-mail that goes out on this.

Hi Brad,

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
having to advertise something about themselves); but I'd like to play Devil's Advocate on this and ask the question.

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.
https://accounts.google.com - Nope - password again.
https://github.com/login - Whoops, a password...
https://www.dropbox.com/login - Yet another password.. and
https://login.salesforce.com/ - Guess what? Password again.

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:

https://fsodemo.strongauth.com/fso/#/ - Hmmmm.. Where's the password?
https://fidodemo.strongauth.com/pnoc - What? The password is a secondary choice?

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.

Arshad Noor
StrongAuth, Inc.

@devd

This comment has been minimized.

devd commented Jul 9, 2017

adding a note from the Dropbox side, I do think this will tremendously help us too. Not sure the PR #379 solves the problem Brad is pointing out though: if I am reading the top level comment right, there will be a permission prompt?

@AngeloKai

This comment has been minimized.

Contributor

AngeloKai commented Jul 9, 2017

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

@AngeloKai

This comment has been minimized.

Contributor

AngeloKai commented Aug 16, 2017

Closing as the related PR is merged: #379

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment