Re: working on re-authentication


> this SC is not implementable by authors since the only solution to it is
biometrics - which a page author cannot do.

   - (*WordPress!... and FREE!**!!*




   - and of course:

Gregg, bottom line, it's do-able today.


On Wed, Dec 20, 2017 at 11:20 AM, Gregg Vanderheiden GPII <> wrote:

> I still don’t see how you can require an AUTHOR to provide an
> authentication method ( or re-authentication — which is authentication)
> without requiring any information beyond  publicly available information (
> not good for authenticating)  or their country ID  (which I would NOT want
> to give to any and all websites that have sign in.
> As such this SC is not implementable by authors since the only solution to
> it is biometrics - which a page author cannot do.
> Am I missing something?
> G
> On Dec 20, 2017, at 11:30 AM, lisa.seeman <> wrote:
> Hi Alastair
> The reason it *might *be ok to allow transcribing etc at sign up, is that
> it might be reasonable for someone to get help the first time they use the
> site, but completely unreasonable to expect the user to have help each time
> they sign in. It is a compromise if people felt that we *have to* allow
> people to copy in a code first time. (Which is why i thought you had tried
> to limit the scope to re-authentication. )
> If we can live without the exception that is better.
> All the best
> Lisa Seeman
> LinkedIn <>, Twitter
> <>
> ---- On Wed, 20 Dec 2017 18:08:08 +0200 *Alastair
> Campbell< <>>* 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!

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.

Advancing the mission of digital accessibility and inclusion

Received on Wednesday, 20 December 2017 17:46:24 UTC