NIST digital identity guidelines feedback

To the RQTF 

Following up on my action to read the NIST Digital Identity Guidelines: https://pages.nist.gov/800-63-3/sp800-63b.html Here's some thoughts. 

I had a chance to read this today.. To put a few caveats around my response I have to acknowledge its quite dense and technical reading for me and although I could understand conceptually most of the discussion, some of the context may be lost so may be worth another read from someone with more technical knowledge. 

That said, I think in  broad terms our current CAPTCHA work does reflect most of the conceptual information here although not to the technical depth and focus on the broader security question. The discussion seems to be on different authentication levels and look s at a variety of hardware, software and user interactions in different authentication scenarios. This information is largely covered in Section 4 and one possible relevance to our CAPTCHA guidance is that we could potentially restructure our guidance against each ofr the authentication level requirements here if it was felt these guidelines provided a good framework for this.  I don't have enough understanding of the importance of these guidelines to know if that would be helpful for our Note.  

   Looking at CAPTCHA specifically and disability specifically, the main sections of relevance are section 5 and 10 in my view, where there is a specific reference to CAPTCHA as a fallback mechanism, presumably a reference to traditional CAPTCHA given its differentiation from the discussion in Section 5.1. To quote: 

"5.2.2 Rate Limiting (Throttling)
When required by the authenticator type descriptions in Section 5.1, the verifier SHALL implement controls to protect against online guessing attacks. Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100.

Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out as a result of rate limiting. These include:

Requiring the claimant to complete a CAPTCHA before attempting authentication.

Requiring the claimant to wait following a failed attempt for a period of time that increases as the account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour).

Accepting only authentication requests that come from a white list of IP addresses from which the subscriber has been successfully authenticated before.

Leveraging other risk-based or adaptive authentication techniques to identify user behaviour that falls within, or out of, typical norms. These might, for example, include use of IP address, geolocation, timing of request patterns, or browser metadata.

When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for that user from the same IP address."  " 

There's quite a lot of different authentication processes discussed here, some identify the user and some don't, so our definition of CAPTCHA I reckon is a lot wider than what is viewed here. 

In terms of disability-specific contentment there some great information in Section 10 regarding usability, which includes some a crossover with WCAG concepts like the need for good text size, high  contrast and other accessibility-related requirements. 

Perhaps the biggest downside  to the document is it looks like its last major update was in 2020, so some of the cutting-edge CAPTCHA work we've been looking at isn't covered here so while some of the information here could add some value to our CAPTCHA guidance, I didn't see anything personally that I thought was radical or revolutionary that we hadn't already considered. However as noted by my caveat at the top someone with more technical understanding may find a hidden gem that I missed and in terms of the broad question of its relevance, it's definitely relevant! It just depends I feel on how well recognised these guidelines are and if we should do more to align our CAPTCHA information to them.  

Scott. 

Dr Scott Hollier  
CEO & Co-founder 
  
Centre For Accessibility Australia Ltd. 
Phone: +61 (0)430 351 909
Email: scott.hollier@accessibility.org.au
Address: Suite 5, Belmont Hub, 213 Wright Street, Cloverdale WA 6105 

accessibility.org.au 
Subscribe to our newsletter
   

CFA Australia respectfully acknowledges the Traditional Owners of Country across Australia and pay our respects to Elders past, present and emerging  

-----Original Message-----
From: Jason White <jason@jasonjgw.net> 
Sent: Friday, February 17, 2023 11:09 PM
To: Scott Hollier <scott.hollier@accessibility.org.au>
Cc: Janina Sajka <janina@rednote.net>
Subject: Re: Following up on RQTF action

Thank you, Scott. I would be interested in your view of relevance. Here’s the link https://pages.nist.gov/800-63-3/sp800-63b.html


The interesting material, as I recall, starts in section 4.
Regards,
Jason.



> On Feb 17, 2023, at 00:41, Scott Hollier <scott.hollier@accessibility.org.au> wrote:
> 
> To Jason and Janina
>  Hope lal is well!
> 
> Jason: in QTF I took an action to read the US government document to 
> see if there were any CAPTCHA implications but I don’t think the link is in the minutes. Could you please send it to me?  Thank you  Scot.
>  Dr Scott Hollier
> CEO & Co-founder<image001.png>
>   Centre For Accessibility Australia Ltd. 
> Phone: +61 (0)430 351 909
> Email: scott.hollier@accessibility.org.au
> Address: Suite 5, Belmont Hub, 213 Wright Street, Cloverdale WA 6105  
> accessibility.org.au Subscribe to our newsletter<image002.gif>  
> <image003.gif> <image004.gif> <image005.gif> CFA Australia 
> respectfully acknowledges the Traditional Owners of Country across Australia and pay our respects to Elders past, present and emerging

Received on Monday, 27 February 2023 05:52:26 UTC