Re: Mikes request that we identify an upper limit on the number of digits

Hi Lisa,

In this case I think showing the feasibility is more important. Mike might disagree, but it would certainly make the requirements easier to sell if there were one or two simple solutions.

I think there are 3 main scenarios that cover a good range of situations for web content. It has been difficult to work out what should/would work as those questions generate a lot of possibilities, and then we go in circles about what works or doesn’t. I know the SC is asking for ‘alternatives’ to the standard, but there still have to be ways to implement these alternatives, and that is not clear yet.

If we can show a reasonable method of implementation for these 3, it will go a long way to putting people at ease.

Here’s what I’ve worked out so far, the main questions start with an asterisk (*):


  1.  A site that currently does a simple username/password.

My understanding is that an email-reset works for this scenario. Ideally it would auto-log you in from the link in the email, but at a minimum you set a new password (even if you never intend to save it) and can login.

* Is the intent that the email reset logs you in automatically? A typical implementation would have you copy the new password into a username/password form to login.



  1.  A site that does username/password plus a second factor, such as an app that generates a 6 digit number every 30 seconds (like Google Auth<https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en_GB>).

I assume that transferring 6 digits across from a phone app to your computer with a time-limit is a big problem, but is there a feasible alternative? (You can put SMS methods in this category as well, although they are considered less secure<https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin>.)

For hardware / biometrics, the only standards based way to enable that on a website (that I know of) is the Web Authentication JavaScript API<https://www.w3.org/TR/webauthn/> to a “Universal Second Factor” (based on FIDO<https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html> I think). We shouldn’t worry about the hardware side as there are many possibilities, but we do need to worry about whether they work with browsers.

The current browser support is Chrome-only<https://caniuse.com/#search=fido>, and that is desktop-only as the U2F devices generally use USB.

* Is there another way that I’m missing? Otherwise I can’t see how we could get 2 implementations (which is probably why WebAuth is still in draft).

Also, how do you get past the username/password bit? You can set the second factor to remember your device for a set time (usually 30 days), but at some point you would still have to login with a password and with the 2nd factor, otherwise there is no security.



  1.  A site like scenario 2 (username/password + 2FA), but provides your email so you can’t use a email-reset loop.

E.g. if you are logging into Gmail / Outlook (web), this is another level of complexity on scenario 2.

So it has all the issues from scenario 2, but with the added complication that you cannot rely on an email-reset loop.

* I can’t see any solution to this one, so perhaps that would need an exception?

Overall:
I think answering the scenarios here would cover these comments on github: 354, 440, 441, 473, 503, 542, 553.
If we can work it out, I’ll put in the responses.

However, it appears to me that the implementations (in the browsers) are not ready yet, and it should be delayed until that changes.

Kind regards,

-Alastair