W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2017

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

From: David MacDonald <david100@sympatico.ca>
Date: Tue, 28 Nov 2017 07:36:28 -0500
Message-ID: <CAAdDpDYL3GBRxe-J722dscjKU09=KpC7iNPfpd6E3o3ygCT+Rw@mail.gmail.com>
To: Alastair Campbell <acampbell@nomensa.com>
Cc: "lisa.seeman" <lisa.seeman@zoho.com>, "W3c-Wai-Gl-Request@W3. Org" <w3c-wai-gl@w3.org>
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
>
Received on Tuesday, 28 November 2017 12:36:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:18 UTC