Re: working on re-authentication

At the risk of muddying the water even more...

I have a minor concern/issue (maybe?) with device form-factors and
multi-factor authentication, although that may only be an issue at the
Techniques level. Allow me to explain...

Just this week, I upgraded my phone to the new Galaxy 8 Note (nice unit
BTW), and on more than one occasion while re-establishing existing
services, when the site in question needed to send the 2nd code via SMS,
the new device automatically accepted it (i.e. it auto-magically continued
the process, by auto-accepting the code without me even seeing it - as if
my phone was actively 'waiting' to get the text message with the security
code).

Clearly, something like this is beneficial to the primary audience that
this SC is targeted towards, but that technique (solution) is/will be
dependant on which device is being used by the end user, and specifics
related to that device.

But it does raise an interesting question: given that these mobile devices
are increasing in power all the time (my Note has more computing power in
it than the lunar lander had in 1969), and they are becoming for many users
their de facto "computers" - my younger daughter for example rarely uses
her laptop anymore: she can do all she needs to do 90% of the time directly
from her phone. To me, the only difference is that her phone has a
persistent unique 'identifying' number (her phone number), whilst her
laptop gets a random DHCP IP Address - conditions beyond her immediate
control (yes, I could help her hack a permanent IP address for her laptop
if so required, but that's not scalable.)

So the question is then, how much of this is centered around author-created
content, and how much is dependant on device API's (etc.) and the actual
devices in question? My experience over the weekend leads me to believe
that this 'problem' is already shaping up with some kind of solution, at
least some of the time, that is completely device based.

Noting this formally now, so that it doesn't slip through the cracks -
we'll need to offer up some kind of warning or note in use-cases such as
this, although I'm not clear today what we would be saying (exactly)...

JF

On Wed, Dec 20, 2017 at 10:08 AM, 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!
>



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

Advancing the mission of digital accessibility and inclusion