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

Re: working on re-authentication

From: lisa.seeman <lisa.seeman@zoho.com>
Date: Wed, 20 Dec 2017 19:19:12 +0200
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: "Alastair Campbell" <acampbell@nomensa.com>, "Andrew Kirkpatrick" <akirkpat@adobe.com>, "Michael Gower" <michael.gower@ca.ibm.com>, "Rochford, John" <john.rochford@umassmed.edu>, "W3c-Wai-Gl-Request@W3. Org" <w3c-wai-gl@w3.org>
Message-Id: <16074edd100.edd76218120737.3644907576709848983@zoho.com>
will make this change to the wording. Thanks Laura

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Wed, 20 Dec 2017 19:10:31 +0200 Laura Carlson&lt;laura.lee.carlson@gmail.com&gt; wrote ---- 

Hi Lisa, Alastair, and all, 
In the third bullet is the adverb "reliably" needed? If not, perhaps 
we could consider cutting it to "produce gestures" or simply 
Kindest Regards, 
On 12/20/17, Alastair Campbell &lt;acampbell@nomensa.com&gt; wrote: 
&gt; Hi Andrew, 
&gt; I agree we should be able to answer those, I just updated the wiki page and 
&gt; I think this version helps: 
&gt; ————- 
&gt; Re-authentication processes do not rely upon the user to do any of the 
&gt; following: 
&gt; - memorize information; 
&gt; - perform calculations; 
&gt; - reliably produce gestures; 
&gt; - transcribe information. 
&gt; Exceptions: 
&gt; - Re-authentication process can rely on the user or user-agent entering 
&gt; personal identification information such as name, username, address, email 
&gt; address or national identification number if the web content does not block 
&gt; automatic entry. 
&gt; - There are governing statutory requirements that require the use of 
&gt; memorisation, calculations, gestures or transcription in re-authentication 
&gt; processes. 
&gt; ————— 
&gt; On your questions: 
&gt;&gt; 1. Regarding user’s abilities to memorize information, don’t browser/OS 
&gt;&gt; capabilities or separate tools (e.g. splash ID, LastPass, etc) 
&gt; I think the first exception covers that now, and yes, I think we need to 
&gt; except that is a user-agent &amp; education issue rather than content, so long 
&gt; as content doesn’t prevent their use (which is also accepted security best 
&gt; practice, despite certain banks thinking otherwise). 
&gt;&gt; Regarding the ability to transcribe information, this includes: 
&gt; Anything where you see/hear characters and have to type them in somewhere. 
&gt;&gt; Regarding the ability to transcribe information, what kind of barrier does 
&gt;&gt; this create for users – is it a complete barrier or something less? In one 
&gt;&gt; of the current options it seems that transcribing a one-time code is ok 
&gt;&gt; for the first time – why is it not a barrier the first time but is a 
&gt;&gt; barrier after that? 
&gt; In usability testing, which wasn’t exactly on this, but close as we gave 
&gt; people made-up information to type in as part of usability testing, it can 
&gt; take 5-10 seconds per character, if they are patient and motivated. The 
&gt; typical time-based-one time code is 6 characters to type in within 30 
&gt; seconds. 
&gt; We can discuss degree, but personally I’ve seen enough to know it is a real 
&gt; issue and any transcription will prevent some people from completing that 
&gt; task. 
&gt; I don’t think we were saying some transcription is ok the 1st time, but that 
&gt; you could set/reset your password? Not sure where that came from. In the 
&gt; above SC text you can: 
&gt; - rely on a password manager so long as you don’t block it. 
&gt; - use a magic-link or email loop password reset. 
&gt; - use webauth for 2nd factor. 
&gt;&gt; It seems that there is a possible conflict with 1.1.1. In that SC there is 
&gt;&gt; language about using CAPTCHA, which is sometimes used as part of an 
&gt;&gt; authentication process. 
&gt; *Generally* I’ve seen it used in account creation rather than 
&gt; authentication, but I guess that can happen. 
&gt;&gt; It seems that providing a multi-modal approach which uses but doesn’t rely 
&gt;&gt; exclusively on visual CAPTCHA is ok under 1.1.1 but may be forbidden in 
&gt;&gt; this SC? 
&gt; Yes, as that involves transcription (which can be either visual or auditory, 
&gt; I don’t think we can discriminate here ;-) 
&gt; So I think it prevents CAPTCHA for being used for re-authentication, but not 
&gt; account creation or authenticating the 1st time in a browser. I think there 
&gt; is good argument for that, as CAPTCHA should not be used if you have already 
&gt; proven you’re not a robot. 
&gt; The current 2.0 SC is still useful for the multi-model aspect. 
&gt;&gt; Are there examples of sites that currently pass the proposed SC language 
&gt;&gt; without relying on the exceptions? 
&gt; Yes, in the above form just having a username/password is fine. If you block 
&gt; pasting then you’d need to provide an email alternative. 
&gt; With second factor it gets more difficult, as you need to off-load the 2nd 
&gt; factor onto an OS/hardware device, which Chrome supports now, and others 
&gt; support soon. As Chrome supports webauth now I assume there are some google 
&gt; sites which support it, and as it can be used as an alternative method (e.g. 
&gt; time-based code OR webauth), I’m sure we can find some. 
&gt; Cheers, 
&gt; -Alastair 
&gt; PS. The 10 years of listening to security podcasts are finally coming in 
&gt; useful! 
Laura L. Carlson 
Received on Wednesday, 20 December 2017 17:19:40 UTC

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