Re: working on re-authentication

will make this change to the wording. Thanks Laura

All the best

Lisa Seeman

LinkedIn, Twitter





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

Hi Lisa, Alastair, and all, 
 
In the third bullet is the adverb "reliably" needed? If not, perhaps 
we could consider cutting it to "produce gestures" or simply 
"gesture". 
 
Kindest Regards, 
Laura 
 
On 12/20/17, 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