Re: working on re-authentication

Hi Laura

Among the sufficient techniques are allowing any one of the following:


Complying to https://www.w3.org/TR/webauthn/ and allowing one component method such as biometrics , FIDO or tokens 

A cheap and easy way is "logon via facebook" (being already logged in to third-party authentication services ).

Using  multi-factor identification with Bluetooth or generate a RC code (on the browser) or simply send a link. I have sent links in other emails to places that do multi-step authentication in fully conformant ways. Also you can use what ever way you want as long as there is an alternative that is conformance 

Automatic user authentication based upon the use of a trusted device (to which the user has already logged in with their own identity);

Fast IDentity Online (FIDO), password-free standards for typical and two-factor authentication.

FIDO relies upon user authentication based upon a user's device (e.g., phone, tablet, computer).

A user's device registers the user, to a server, via a public key.

Upon a challenge from the server, the user's device responds with a private key.

The device's keys are unlocked by the user biometrically (e.g., fingerprint scanner) or by a button press, not by a password.

Allowing the user to reset a password by pressing a link sent to them in an SMS or email.sms, which brings the user to a page that provides the opportunity to create a new username and/or password
Being compatible with password managers that allow user login with one of the above techniques.



All the best

Lisa Seeman

LinkedIn, Twitter





---- On Wed, 20 Dec 2017 19:39:30 +0200 Laura Carlson<laura.lee.carlson@gmail.com> wrote ---- 

Hi Gregg and Lisa, 
 
I think it may come down to techniques. Lisa, what author techniques 
for this SC are in the works? 
 
Thanks. 
 
Kindest Regards, 
Laura 
 
On 12/20/17, 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> 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