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

Re: working on re-authentication

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

Laura L. Carlson
Received on Wednesday, 20 December 2017 17:11:04 UTC

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