Re: working on re-authentication

@Gregg:

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

   - https://wordpress.org/plugins/launchkey/ (*WordPress!... and FREE!**!!*
   )

   -
   https://www.quora.com/Can-we-use-biometric-authentication-in-web-applications

   - https://coaxsoft.com/blog/biometric-authentication-ruby-rails/

   -
   https://www.pcworld.com/article/3055720/internet/you-can-try-out-windows-hello-biometric-logins-for-the-web-right-now.html

   - and of course:
   https://www.google.com/search?q=how+to+add+biometric+authentication+to+your+web+site

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

JF

On Wed, Dec 20, 2017 at 11:20 AM, Gregg Vanderheiden GPII <
gregg@raisingthefloor.org> 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 <lisa.seeman@zoho.com> 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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Wed, 20 Dec 2017 18:08:08 +0200 *Alastair
> Campbell<acampbell@nomensa.com <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!
>
>
>
>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion