[WCAG 2.2 Draft Feedback] Success Criterion 3.3.7 Accessible Authentication (Level AA)

[dshoukry]

Accessible Authentication (AA)
“Success Criterion 3.3.7 Accessible Authentication - A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

• Alternative Another authentication method that does not rely on a cognitive function test.
• Mechanism A mechanism is available to assist the user in completing the cognitive function test.
• Object Recognition The cognitive function test is to recognize objects.
• Personal Content The cognitive function test is to identify non-text content the user provided to the website.”

Recommendation:
Most of our comments/proposals are requests to: remove general object recognition due to security concerns, provide more risk mitigation tactics, and to explicitly clarify two definitions and examples.

Please find detailed specifics covered in our Sep22 3.3.7 Accessible Authentication (AA) Google Doc

[alastc]

Suggested response for the group to consider:

---

Some responses to the comments (including the comments from the doc for context):

There was a suggestion to add this into the SC text:

"Alternatives to cognitive function tests include webauthn-based authentication, in which the user typically performs a biometric check (fingerprint or face recognition) instead of typing a password."

We would not call-out a specific technology in SC language (it is one of the requirements), or use an example in the SC text. I've created PR #2811 and included the suggested biometric example in the note underneath.

So, for Object Recognition - if that means CAPTCHA-like systems like "which of these images show a crosswalk", etc. - those won't work for authentication, because other users can also do them. If, on the other hand, we mean something like "which of these images shows your car", then that's ok (because presumably the attacker won't know which of the cars shown is the right one to select). But those seem better captured by the "Personal Content" category?

The reason the object recognition exception is included is for companies like Google that sometimes, due to suspected abuse, will include a CATPCHA during the authentication process.

I agree that it is not authentication per-se, but we've found these are included during the process. For example, if there are too many hits from a particular IP address a CAPTCHA may be added to the page. (Personally I'd be very happy to remove that exception, but I don't think we'd get it through.)

There was a suggestion to add this to the Personal Content exception:

Care must be taken to provide adequate security in this case, since non-legitimate users might be able to guess the correct personal content when presented with a choice, especially when given multiple attempts to guess. This option should be used in conjunction with other authentication steps, or other risk-mitigating mechanisms, to reduce the likelihood of a successful account-takeover attack.

This is potential content for the understanding document, rather than the SC text. I've added a short section in the understanding document to make clear what it is, and your concern about security.

There was a suggested note:

If the authentication method requires the user to input specific chunks of information, such as a specific line of digits from their social ID, then it is a more substantial cognitive test than asking the user to enter the full piece of information. This is because the form is now requesting the user to analyze patterns within a large piece of content. The cognitive test is made even more difficult because different systems may request different chunks of the full piece of information (e.g., some interfaces may request the last 3 digits, while others ask for the first 5 digits).

This is good information, but is it needed? The preceding paragraph says: "using a different format between the copied text and the input field (for example, "Enter the 3rd, 4th, and 6th character of your password"), would force the user to transcribe information and therefore fail this criterion".

It seems to be extending the document to include more about something we say fails the criterion.

There was also a suggested note:

When providing the option to show password, it should be in a format that is toggled on and off and persistent in the selected new state until the user changes the state again. This way, the user can see the characters and type at the same time. Mechanisms that require a continuous input for the password to be shown (e.g. an icon has to be pressed and if unpressed, the characters are hidden again) are not recommended as the user will not be able to type while seeing their password unhidden. This could be characterized as a barrier both for individuals with motor disabilities, and those with cognitive disabilities.

The proceeding paragraph is a 'best practice', rather than something we can say passes (or fails) the SC. It is tangential. Therefore I'm reluctant to add more about that. In the PR I've updated the current paragraph to say "Providing a feature to toggle the visibility of password", hopefully that helps.

Sidenote: We are not supposed to use must/should/may language in the understanding documents, apparently people have read that as adding requirements to the SC.

[dshoukry]

Suggested response for the group to consider:

Some responses to the comments (including the comments from the doc for context):

There was a suggestion to add this into the SC text:

"Alternatives to cognitive function tests include webauthn-based authentication, in which the user typically performs a biometric check (fingerprint or face recognition) instead of typing a password."

We would not call-out a specific technology in SC language (it is one of the requirements), or use an example in the SC text. I've created PR #2811 and included the suggested biometric example in the note underneath.

Thank you!

So, for Object Recognition - if that means CAPTCHA-like systems like "which of these images show a crosswalk", etc. - those won't work for authentication, because other users can also do them. If, on the other hand, we mean something like "which of these images shows your car", then that's ok (because presumably the attacker won't know which of the cars shown is the right one to select). But those seem better captured by the "Personal Content" category?

The reason the object recognition exception is included is for companies like Google that sometimes, due to suspected abuse, will include a CATPCHA during the authentication process.

I agree that it is not authentication per-se, but we've found these are included during the process. For example, if there are too many hits from a particular IP address a CAPTCHA may be added to the page. (Personally I'd be very happy to remove that exception, but I don't think we'd get it through.)

We agree that CAPTCHAS and other object recognition tests are indeed sometimes used to gather additional risk signals during authentication flows, and it's important to point out that they're compatible with Level AA accessibility guidelines. They can't be used by themselves, however, to authenticate users. Could we perhaps add the following to the bullet point 'Object Recognition: The cognitive function test is to recognize objects.' in section 3.3.7:

"Object Recognition: The cognitive function test is to recognize objects. Note that this test is useful for mitigating certain automated attacks, but it can't be used by itself to authenticate individual users. If used during authentication, it needs to be combined with one or more other authentication steps, which must meet the requirements described here."

There was a suggestion to add this to the Personal Content exception:

Care must be taken to provide adequate security in this case, since non-legitimate users might be able to guess the correct personal content when presented with a choice, especially when given multiple attempts to guess. This option should be used in conjunction with other authentication steps, or other risk-mitigating mechanisms, to reduce the likelihood of a successful account-takeover attack.

This is potential content for the understanding document, rather than the SC text. I've added a short section in the understanding document to make clear what it is, and your concern about security.

Thank you!

There was a suggested note:

If the authentication method requires the user to input specific chunks of information, such as a specific line of digits from their social ID, then it is a more substantial cognitive test than asking the user to enter the full piece of information. This is because the form is now requesting the user to analyze patterns within a large piece of content. The cognitive test is made even more difficult because different systems may request different chunks of the full piece of information (e.g., some interfaces may request the last 3 digits, while others ask for the first 5 digits).

This is good information, but is it needed? The preceding paragraph says: "using a different format between the copied text and the input field (for example, "Enter the 3rd, 4th, and 6th character of your password"), would force the user to transcribe information and therefore fail this criterion".

It seems to be extending the document to include more about something we say fails the criterion.

There was also a suggested note:

When providing the option to show password, it should be in a format that is toggled on and off and persistent in the selected new state until the user changes the state again. This way, the user can see the characters and type at the same time. Mechanisms that require a continuous input for the password to be shown (e.g. an icon has to be pressed and if unpressed, the characters are hidden again) are not recommended as the user will not be able to type while seeing their password unhidden. This could be characterized as a barrier both for individuals with motor disabilities, and those with cognitive disabilities.

The proceeding paragraph is a 'best practice', rather than something we can say passes (or fails) the SC. It is tangential. Therefore I'm reluctant to add more about that. In the PR I've updated the current paragraph to say "Providing a feature to toggle the visibility of password", hopefully that helps.

Yes, thank you!

Sidenote: We are not supposed to use must/should/may language in the understanding documents, apparently people have read that as adding requirements to the SC.

Noted :-)

[alastc]

HI @dshoukry,

On the remaining point:

Could we perhaps add the following ...
"Object Recognition: The cognitive function test is to recognize objects. Note that this test is useful for mitigating certain automated attacks, but it can't be used by itself to authenticate individual users. If used during authentication, it needs to be combined with one or more other authentication steps, which must meet the requirements described here."

In the SC text, we aren't concerned about why such a thing pops up (authentication or not), it is whether it is part of the authentication process or not. Without the exception, any cogntive-function test required for completing authentication is in scope. The exception allows for some types of CFT.

The suggestion is too specific for the SC text, but in the understanding document we already have:
"Some CAPTCHAs and cognitive function tests used for authentication may only appear in certain situations, such as when ad blockers are present, or after repeated incorrect password entry. This criterion applies when these tests are used regardless of whether they are used every time or only triggered by specific scenarios."

I think that's covering the same area?

[alastc]

The responses above were approved by the group:
https://www.w3.org/2023/02/07-ag-minutes#item07

So closing this issue.

If you have any further comments (e.g. on the last point above), please comment here and we can look at updating the understanding doc.

[dshoukry]

Thank you!

We agree with the following text: "Some CAPTCHAs and cognitive function tests used for authentication may only appear in certain situations, such as when ad blockers are present, or after repeated incorrect password entry. This criterion applies when these tests are used regardless of whether they are used every time or only triggered by specific scenarios."

We have some concerns with an implementer reading the following: "A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step [is] Object Recognition [or one of the other exceptions]".

We're concerned that an implementer might interpret "one way to implement an authentication process compatible with WCAG is to use CAPTCHA, and only CAPTCHA". That would be an authentication process that is compatible with WCAG, but it would be one that is somewhat insecure.

How should we (or should we at all) address this issue? Should we include language that guides implementers away from insecure implementations (without sacrificing any of the WCAG guidelines, of course)? Or is the scope purely focused on accessibility guidelines, and assume that implementers have some other way to educate themselves about security? If the answer to the last question is "yes", then we agree the text as written is okay. But if we want to give some guidance on how to navigate accessibility and security, then we still believe some language to that effect (i.e., that CAPTCHAs alone cannot be used to authenticate users) should be included.