Re: going though comments from 2.2.6 Accessible Authentication and new wording.

Hi Gregg

There are a lot of good techniques these days that conform.

Using the web authentication specification is one of them, as is FIDO, using multi step with an option such as RQ codes, tokens or Bluetooth, 


Cheap and easy  low security options included allowing a login in via facebook or other conformant provider , or allowing the user to reset their password by clicking on a link sent to their email.

there are more but I think that is all I have time to lookup right now.
All the best

Lisa Seeman

LinkedIn, Twitter





---- On Tue, 19 Dec 2017 17:22:33 +0200 Gregg Vanderheiden GPII<gregg@raisingthefloor.org> wrote ---- 

Hmmmm


this still is using publicly obtainable information for authentication such as name address email address (bad idea)  or their  national ID number which is a very bad idea to be giving out on every website -=- and how would the website know it anyway. (also a bad idea). 


other than that — the only thing I know of is  biometrics which the computer does not have the ability to carry out.


am I missing something?    


Gregg


 









On Dec 19, 2017, at 9:50 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:

Hi Alister

1. - good point. I changed the first exception to - Re-authentication process only relies on


2. for web authentication spec . You already sent us the link to Chrome, I sent some links in my email in November 29th with regard to the implemention.
" 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/) - there may be better links but these seem to show that enough features are implemented to meet our needs for conformance to our SC. So implementations seem in place . Also according to the charter you sent us they intend to be in CR now, which would make it a mature draft.


3. "> 2. the only type of multi-factor identification that is bared is on involving coping a code.  Without webauth, that is all (standardized) multifactor options available via the browse "
 You can  use multi-factor identification with Bluetooth or generate a RC code (on the browser) or simply send a link. I have sent links in other emails to places that do multi-step authentication in fully conformant ways. Also you can use what ever way you want as long as there is an alternative that is conformant 
4 ">In which case, we could re-scope the SC to ensure that sites which do use 2 factor make it simpler for re-authentication:"
There are many new ways that people are coming out with for authentication that bar people with cognitive disabilities, such as remembering a pattern, coping the 5th item in a sequence  etc. This does not address all of the weird new things people come out with but it does, for now, address the worst offenders  

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Tue, 19 Dec 2017 16:22:14 +0200 Alastair Campbell<acampbell@nomensa.com> wrote ---- 

Hi Lisa,
 

> Some key points for the call today on accessible authentication for the wording draft  at https://www.w3.org/WAI/GL/wiki/2-2-6_Revision  
 

That’s a good improvement, but it still has the hole in the 1st exception: If authentication involves email (e.g. using your email as username), then the whole process is exempt. I don’t think that is the intention?
 

I suggest: “Re-authentication process only relies on basic personal identification information”
 

 

> 1.  we were concerned that web authentication specification which is a great standard way to meet this SC was not mature enough and did not have implementations. However this specification is now at wide review version and is on track for CR. 
 

Which means 2nd Quarter 2018 according to their charter, is that in time to be useful?
https://www.w3.org/2017/08/web-authentication-charter.html
 

 

> They have implementations in Microsoft Edge, the Google Chrome and the Mozilla Firefox browsers and working in different operating systems. (See https://www.w3.org/blog/webauthn/)
 

Their blog is not very clear, I’ve been searching for the implementation status on FF & Edge, the best I can find is:
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/fidou2f/ (not planned)
https://bugzilla.mozilla.org/show_bug.cgi?id=1294514 (Worked on, but hard to determine progress).
 

When they say “implementations”, that does not mean they are publically available in browsers yet. The firefox one is behind a flag, I’m still not clear where to find the MS one.
 

Also, remember that webauth is useful when you are not using multiple factors, in the multi-factor scenario it replaces one factor, and you still need a username/password (or code to copy across).
 

 

> 2. the only type of multi-factor identification that is bared is on involving coping a code. 
 

Without webauth, that is all (standardised) multifactor options available via the browser.
 

 

> This method is being activity depreciate by NIST as insecure. 
 

No, that is just SMS. The popular Googe-auth/authy style 2FA still in wide use. (I have a dozen codes active in my app for google, Microsoft, amazon, dropbox, hosting companies etc.)
 

 

> 3. the use of a passport manager can be an allowed technique so long as specific conditions are met …
 

I assume you mean password manager here, and as I said 1st Dec:
 

I’d be happy to have an SC about not blocking password managers, it would fit nicely under guideline 4.1, something like:
“Assisted Authentication: User interface components which gather authentication credentials do not prevent automatic entry.”
 

NB: Not marking up an input as password properly could be failed under 1.3.1 and possibly 4.1.1 already.
 

However, we are a bit late in the 2.1 cycle for a new SC!
 

So the question is: Would you like to proceed with this (in my view) redundant SC requiring sites to provide a non-password method of re-authentication for single-factor auth?
 

The only other (useful) option I can see is that we assume people can use a password manager.
 

In which case, we could re-scope the SC to ensure that sites which do use 2 factor make it simpler for re-authentication:
-----------
Essential steps of a multi-factor re-authentication process which relies on recalling or transcribing information has alternative essential steps which do not rely upon recalling or transcribing information, unless there are legal requirements for a recall or transcribe method of authentication.
-----------
 

That basically says: You can use username/password, but for 2nd factor you have to provide a mechanism for re-authentication which doesn’t require typing things in.
 

The options for that are then:
Save the person’s cookie, only re-auth after 30 days or with a new browser.
WebAuth (later).
‘Magic’ link.
 

Having it apply to second-factor re-auth makes it more feasible.
 

 

> 04. we asked the web authentication group for feedback months ago, and we also performed and passed a security audit on this success criteria.
 

That is good, but that does not mean it is feasible to do across all web sites.
 

Kind regards,
 

-Alastair