RE: Feedback on Success Criterion 2.2.6 Accessible Authentication

Hi Lisa,

So the security review shows that it is possible to achieve the SC securely, which is what I expected, I’ve been arguing it is not possible to achieve feasibly for many organisations/sites.

The open questions (blockers in my view) from my previous emails on this are:


  *   Is it required to be able to use the alternative every time? I haven’t found any implementation that supports that as they all require you to use a password occasionally. However, if we except that, the SC doesn’t make sense to me.

  *   Is an email reset loop ok? (Compared to the ‘magic link’ approach from Slack/linkedin). In the vast majority of password-reset implementations you have to create a new password then enter it to login. In the current SC I don’t think that would conform?

  *   Where an organisation wants to use 2nd factor auth, is there a non-browser specific, cheap method of supplying it?
(Maintaining mobile apps, paying for SMS gateways, and custom token infrastructure are not at all cheap. I’m not sure that Fareclock can be applied to any website, but in any case that’s a monthly cost.)
Yes there are lots of ways of doing external authentication, but until WebAuth is more than Chrome-only, there is a huge infrastructure cost to a website providing it.

So the techniques we’ve uncovered for the 3 scenarios I outlined are:


  1.  A site that currently does a simple username/password.
     *   After having created a username/password, allow a ‘magic link’ email login.

     *   When a user has already logged in with username/password in this browser, allow a 2FA style login where you authenticate on a separate mobile app, or custom USB token generator.

  2.  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).
     *   After having created a username/password, allow a ‘magic link’ email login, AND have a 2FA style login where you authenticate on a separate mobile app, or custom USB token generator.
(Note that slack and I think Linkedin provide 2FA with a number-generator you have to copy across.)

     *   ???

  3.  A site like scenario 2 (username/password + 2FA), but provides your email so you can’t use a email-reset loop.
     *   ??? (I’m sure they provide alternatives, but how do you get into it in the first place?)

We still have big gaps in terms of possible solutions and feasibility, at least until WebAuth is better supported.

Kind regards,

-Alastair


From: lisa.seeman [mailto:lisa.seeman@zoho.com]
Sent: 29 November 2017 06:16
To: W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org>
Subject: Feedback on Success Criterion 2.2.6 Accessible Authentication



Hi
Please find attached the security audit on  2.2.6
All the best... Lisa

Subject : Feedback on Success Criterion 2.2.6 Accessible Authentication
============ Forwarded message ============
Hi Lisa,
I had four people review the SC at the following URL:

https://www.w3.org/TR/WCAG21/#accessible-authentication

Reviewers hold positions in compliance, risk, information security and legal. Two reviewers hold the CRISC certification, one reviewer holds the CISSP certification as well as a a legal degree.
Feedback on wording:
Current

Essential steps of an authentication process, which rely upon recalling or transcribing information, have one of the following:
Suggested (remove commas)

Essential steps of an authentication process which rely upon recalling or transcribing information have one of the following:
Reasoning
The first comma changes the meaning and context of the section after the comma making it a descriptor of an authentication process. The second comma is then not needed.

Current

The authentication process involves basic identifying information to which the user has easy access, such as name, address, email address and identification or social security number;

Suggested (remove reference to social security number)

The authentication process involves basic identifying information to which the user has easy access, such as name, address, email address or identification number
Reasoning

It may be unlawful to use Social Security number for purposes other than tax/income in some case:

http://consumersunion.org/news/state-laws-restricting-private-use-of-social-security-numbers/


Impact on security

All reviewers concluded that, if the suggestion presented above were implemented, this language would not have a negative impact on security.

Authentication is typically defined with three common factors:

  1.  Something you know - The SC recommends against this. This is actually the least secure method of authentication. The SC is recommending against a weak method of authentication which could have a positive impact on security.
  2.  Something you have (a hard token for example) - The SC does not recommend against this and may support it.
  3.  Something you are (biometrics for example) - The SC does not recommend against this and may support it.
We also discussed current implementations that appear to support this SC, for example,


  *   FareClock
  *   LinkedIn - One-time sign-in link
  *   Slack - Magic Link

Let me know if you need any addition information.

Best,
Thaddeus