Re: working on re-authentication

Hi Gregg and Lisa,

I think it may come down to techniques. Lisa, what author techniques
for this SC are in the works?


Kindest Regards,

On 12/20/17, 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!

Laura L. Carlson

Received on Wednesday, 20 December 2017 17:39:54 UTC