Re: Feedback on Success Criterion 2.2.6 Accessible Authentication

Hi Steve,

Having worked at Chase bank for over 3 years, I am quite familiar with
those types of dongles. They have numerous problems, the most significant
being they are often USB dongles. Apple, in their infinite wisdom is making
USB ports a thing of the past, which sucks, but beyond that, it's near
impossible to get a standard USB dongle to interface with a mobile device
(unless that device has a standard USB port - most don't).

Additionally, most of the dongles I've seen use LCD display screens that
are completely inaccessible to low and no vision users. As a technique,
sure, dongles have a place and role to play, but for WCAG compliance, if
the only way to authenticate was via a dongle like that, it would have to
fail due to lack of accessibility support across all platforms.

That said, there are also software/hardware tools emerging that use
Bluetooth to connect to the device, and some of these tools also assist and
manage the storing of passwords (see: https://gkchain.com/halberd.html) -
the point being that we cannot and should not put all of the heavy lifting
on the content developers, as content alone cannot solve all problems.

Cheers!

JF

JF

On Thu, Nov 30, 2017 at 3:46 PM, Repsher, Stephen J <
stephen.j.repsher@boeing.com> wrote:

> Alastair et al,
>
>
>
> I’m not following this in detail, but just so you are aware, there have
> been devices out there doing this without transcription for some time, e.g.
> https://www.yubico.com/security-keys-authentication/?gclid=
> EAIaIQobChMI5LbOuqDn1wIVg-NkCh3TGAE6EAAYASAAEgJYN_D_BwE.
>
>
>
> I have one for a U.S. DoD account, so the first factor is a strong
> password, and the second is by this USB key which enters a very long OTP
> string I never even see to finalize the login.
>
>
>
> I suppose the conversation then falls to our definition of accessibility
> support and how expensive and/or available such things are.
>
>
>
> I apologize if this doesn’t factor into the conversation or was already
> discussed.
>
>
>
> Steve
>
>
>
> *From:* Alastair Campbell [mailto:acampbell@nomensa.com]
> *Sent:* Thursday, November 30, 2017 10:54 AM
> *To:* lisa.seeman <lisa.seeman@zoho.com>; W3c-Wai-Gl-Request@W3. Org <
> w3c-wai-gl@w3.org>
>
> *Cc:* public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
> *Subject:* Re: Feedback on Success Criterion 2.2.6 Accessible
> Authentication
>
>
>
> Hi Lisa,
>
>
>
> As far as I’m aware, there is no reasonable implementation for 2-factor
> that does not include typing in numbers, so it wouldn’t even make AAA.
>
>
>
> That leaves us at a dead end.
>
>
>
> Given that most sites do not require second factor (yet), that seems a
> shame.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
>
>
> *From: *"lisa.seeman" <lisa.seeman@zoho.com>
> *Date: *Thursday, 30 November 2017 at 15:46
> *To: *Alastair Campbell <acampbell@nomensa.com>, WCAG <w3c-wai-gl@w3.org>
> *Cc: *public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
> *Subject: *Re: Feedback on Success Criterion 2.2.6 Accessible
> Authentication
>
>
>
> Hi Folks
>
>
>
> *I asked the coga task force about limiting the scope single-factor* authentication
> process.
>
>
>
>  It was unanimously rejected as in everyone's experience on the call,
> coping the number from an SMS is harder then using passwords, and this
> would push websites towards less accessible authentication. Hence it does
> not benefit the user.
>
>
>
> our proposal is to ask that we we have the current wording and it is
> labeled at risk with a note that it may be moved to AAA
>
>
>
>
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Thu, 30 Nov 2017 11:14:35 +0200 *Alastair Campbell<*
> *acampbell@nomensa.com* <acampbell@nomensa.com>*>* wrote ----
>
> HI Lisa,
>
>
>
> If there is a practical way to have two-factor/step auth that doesn’t
> require typing in numbers/characters I’m all ears, but if there is not a
> reasonable way to do it, it doesn’t make sense to try and require it.
>
>
>
> I suggest that the best-practices doc (which I’d like to help with)
> recommends having long times between authentications. E.g. On Lastpass I
> can tick a box for ‘remember me for 30 days’, so I don’t have to use the
> 2FA numbers for a month.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
>
>
> *From: *"lisa.seeman"
>
>
>
> Hi Alistair
>
>
>
> I like the limitation to  *re-*authentication. That makes sense to me
>
> Limiting  it to single step may be a compromise we have to make but it is
> a problem.
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Wed, 29 Nov 2017 15:26:54 +0200 *Alastair
> Campbell<acampbell@nomensa.com <acampbell@nomensa.com>>*wrote ----
>
> Hi Lisa,
>
>
>
> Sorry for the long email, skip to the end to see the resulting language.
> Details between here and there…
>
>
>
>
>
> > An  email reset loop is ok.
>
>
>
> I’m not sure how a typical email reset-loop would be ok, the steps are
> usually:
>
>    1. Click on ‘forgotten password’
>    2. Put in your email address.
>    3. Receive a link through email, select it
>    4. Put in a new password, twice. Next.
>    5. On the login page, enter your username/email, and password to login.
>
>
>
> That means you have to remember/copy/transcribe the password from one page
> to the next.
>
>
>
> However, I’ll drop this one as there do appear to be common
> libraries/methods for doing direct-login from an email link.
>
> E.g. https://www.drupal.org/project/email_auto_login
>
> https://wordpress.org/plugins/wp-email-login/
>
> https://stackoverflow.com/questions/37332190/django-login-with-email
>
>
>
> That helps in the single-factor case.
>
>
>
>
>
> > Other example of cheap  methods is "login in via Facebook".
>
>
>
> As you say, some won’t like (or cannot use) a 3rd party login, but it’s a
> useful extra.
>
>
>
>
>
> > Facebook itself is conformant as it allows you to login via your profile
> picture (you click on your picture instead of typing in a password.)
>
>
>
> That’s true once you’ve logged in with a username/password, but not if you
> have a fresh browser / different computer.
>
>
>
> *Again: Does the site have to comply all the time?  *They do not now, and
> possibly cannot.
>
>
>
>
>
> > A site can have two step authentication with coping a number from an SMS
> so long as they allow a reset or other conformant mechanism as well.
>
>
>
> How does a reset help? If you reset a password, you still have to put in
> the number from the 2FA whether it is SMS or app based.
>
> Do you mean turning off 2FA?
>
>
>
>
>
> > Note  as the National Institute for Standards and Technology (NIST) in
> July 2016 warned against using the plane text-message-based two-factor
>
>
>
> Yep, I noted that before as well, we shouldn’t use SMS as a technique, not
> that it would be conformant anyway.
>
>
>
>
>
> > Some sites use an RC code generator.
>
>
>
> Random code? Do you mean a QR code generator?
>
>
>
>
>
> > That seems more secure then two step authentication, is completely
> compliant and can be done for free.
>
>
>
> I think you are confusing authentication with *re-authentication*. I.e.
> if you have already logged in (probably with a password), then you can
> re-authenticate with an easier / less secure method.
>
>
>
> Also, can you point to a service that provides this? (I’ve googled for RC
> and QR codes for login but can’t find anything useful.)
>
>
>
>
>
> > RC scans are used by plannerinclusion
>
>
>
> Great, but I can’t find plannerinclusion to see what you mean, is that the
> right spelling?
>
>
>
> What I’m trying to work out is if it is something available for free, or
> as a service, or you have to implement it yourself.
>
>
>
>
>
> > Also the FIDO key can be at the users expense.
>
>
>
> Yep, I’ve read up on how it works. When it is better supported it would be
> a good mechanism for single-factor auth.
>
>
>
> However, it will only help in the single factor case, as from (the link
> you provided to) MS’s FIDO implementation says:
>
>
>
> “The Web Authentication specification defines two authentication
> scenarios: passwordless and two factor. In the passwordless case, the user
> does not need to log into the web page using a user name or password – they
> can login solely using Windows Hello. *In the two factor case, the user
> logs in normally using a username and password*, but Windows Hello is
> used as a second factor check to make the overall authentication stronger.”
>
>
>
> I.e. when you have 2-factor on, there is not a password-less mechanism
> because FIDO/WebAuth*is* the second factor.
>
>
>
>
>
> > Also firefox seem to be quite advanced in their webauth implementation…
> Do you know the source is for saying it only works in chrome?
>
>
>
> Yep, the usual source of browser support facts: https://caniuse.com/#
> search=fido
>
>
>
> I’m sure Firefox and Edge will, as Mozilla and Microsoft have editors on
> the spec. But then the question is when, it is not planned before version
> 60 of Firefox, eta after WCAG 2.1.
>
>
>
>
>
> >  If not can you think of an exception that would help?
>
>
>
> Yes, but not sure how much it helps overall, *bolding* additions/changes:
>
>
>
> --------------
>
> Essential steps of a *single-factor* *re-*authentication process which
> relies on recalling or transcribing information has one of the following:
>
>
>
>    - alternative essential steps, which do not rely upon recalling or
>    transcribing information.
>    - an authentication-credentials reset process, which does not rely
>    upon recalling or transcribing information
>
>
>
> Except that the authentication *process can rely on* the user inputting
> basic personal information such as name, address, email address or national
> identification number.
>
>
>
> *Unless there are* legal requirements for a recall or transcribe method
> of authentication.
>
>
>
> --------------
>
>
>
> Not perfect, but do you see where I’m going with it?
>
>
>
> I was also trying to remove the hole where anything involving a name /
> email address was totally exempt.
>
>
>
> -Alastair
>
>
>
>
>
>
>
>
>
>
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion