RE: Feedback on Success Criterion 2.2.6 Accessible Authentication

Hi Alister

An  email reset loop is ok. Other example of cheap  methods is "login in via Facebook". 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 method is also something a site can use. So every site that allows you to login via facebook is conformant. (Not everyone likes this but it is an option)


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. 
Note  as the National Institute for Standards and Technology (NIST) in July 2016 warned against using the plane text-message-based two-factor authentication. (It's too easy to spoof or to intercept a text message.) (see https://threatpost.com/nist-recommends-sms-two-factor-authentication-deprecation/119507/). Some of the problems with it are discussed here: https://www.eff.org/deeplinks/2017/09/guide-common-types-two-factor-authentication-web. 


Some sites use an RC code generator. That seems more secure then two step authentication, is completely compliant and can be done for free. RC scans are used by plannerinclusion, across Spain and Portugal, by tens of thousands of people with intellectual disabilities, so we know this is another usable alternative.


Also the FIDO key can be at the users expense. Think of it as requiring a user to have a screen reader. the website does not have to pay for the user agent. 


Also firefox seem to be quite advanced in their webauth implementation (see https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication) and looking though the wg minuets it seems Edge also has implementation (https://blogs.windows.com/msedgedev/2016/04/12/a-world-without-passwords-windows-hello-in-microsoft-edge/). Do you know the source is for saying it only works in chrome? Maybe that is only the full feature set from WD5? 
FYI chrome is a free download and it looks like the webauth works on   Windows, Mac, Linux, and Chrome OS. 


Does this address your concern? If not can you think of an exception that would help?


All the best

Lisa Seeman

LinkedIn, Twitter





---- On Wed, 29 Nov 2017 12:27:59 +0200 Alastair Campbell<acampbell@nomensa.com> wrote ---- 

    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:
  
  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.
 
 
 
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.)
 
 
???
 
 
 
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:
 
   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.
 Something you have (a hard token for example) - The SC does not recommend against this and may support it.
 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