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

I've been following the discussion in the minutes and online as much as
possible. It appears to me that there are a number of problems with
requiring this SC.

* It's very hard to do in a secure way
* There is a lack of maturity of methods available, and lack of
implementation support
* It is a requirement for security departments and they don't tend to have
a lot of flexibility when it comes to accommodations that interfere with
security.
* There is not a lot of evidence of threshold levels of characters to copy,
which would be acceptable to people with disabilities.
* Practically speaking, if a user cannot copy a 5 digit code, would they be
able to use a mainstream website, such as a news site etc...

Perhaps I've missed something, but for an SC to be accepted by large
stakeholders such as governments, banks, and incorporated into laws, I
think there has to be momentum behind technology solutions we are
proposing, and it needs to be viable by the mainstream. I confess I'm not
in the middle of this one, and so I may be missing something. But if the
bullet points above are accurate, I'd say we need to put this SC at risk.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, Nov 28, 2017 at 5:02 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> 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 2
> nd 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
>