Accessible Authentication (3.3.7): clarify whether copy/paste is a cognitive function test

[smhigley]

There are some platforms and environments where autofill is not possible, such as a web-based command line interface where authentication is text-only, with no GUI controls or other options.

The definition of a cognitive function test includes transcription, but it isn't entirely clear if the ability to copy and paste a string is a passing method. Allowing copy/paste would completely solve the command line problem, and other non-standard UI examples we've been able to think of (including desktop and mobile apps). It would also still prohibit the following less-than-ideal examples:

• A required text message authentication step that forces a user to transcribe numbers from their phone onto a computer
• A username/password form that disables pasting functionality
• Captchas
• Images of pin numbers or other 2FA strings

The current wording does not seem to explicitly prohibit copy/paste authentication flows, but it would be helpful to note that a single copy/paste step does not count as transcription in the definition of cognitive function test.

[patrickhlauke]

I believe, though I may be wrong, that "transcription" in that definition https://www.w3.org/TR/WCAG22/#dfn-cognitive-function-test was alluding not to things like 2FA fobs, text messages, etc. but rather those "distorted numbers and letters" CAPTCHAs, where the user is presented with an image and are asked to type in what numbers/letters they can perceive there.

[jake-abma]

This has been discussed more than once and my recollection of this is that is was not allowed as a means to pass (and yes, under "transcribe") but not sure what the latest consensus is if not mentioned specifically.

Would be good to involve someone from COGA to provide info on the topic.

@rachaelbradley do you know or refer to someone?

[patrickhlauke]

if all those things (2FA etc) are essentially "outlawed" by this SC, i'd say it's exceedingly draconian for a level A...

yes, there are now solutions like WebAuthN etc. but forcing every website (even the smallest little one) to adopt these sorts of quite involved solutions is...optmistic?

[alastc]

Just a couple of clarifications whilst I'm tagging issues:

"Transcription" is intended to mean where you have to read something from one place and enter it in to authenticate.

From my recollection of the conversations with COGA (CCing @JohnRochfordUMMS) - copy/pasting was ok, and things like autofil (e.g. with a browser or password manager) are helpful, so disabling copy/paste is terrible.

There might be some scenarios I'm not considering (where copy/paste wasn't reliable), but in general copy-paste was not intended to be restricted.

[patrickhlauke]

perhaps this is then a case of very clearly spelling out things in the definitions/understanding documents, with ample examples covering many of the things that used on the web today, and saying clearly which ones of these are/aren't passes.

[patrickhlauke]

"Transcription" is intended to mean where you have to read something from one place and enter it in to authenticate

so any external 2FA (physical fob, app on my mobile, etc) is now a fail? what if the authentication needs to happen on something like a public terminal / point of sale type thing, where I simply can't receive an email (so can't have a login email link) or similar (and it's not my device, so it would't have stored my thumbprint or anything else that would allow WebAuthN or similar to work)

[alastc]

so any external 2FA (physical fob, app on my mobile, etc) is now a fail?

No. The external one-time-passcode things (e.g. 6 digits changing every 30 secs) would be, but you can also use:

• The MS authenticator app which provides a 'yes' button when you authenticate.
• The USB dongle things enter the code directly (e.g. yubikey)
• Google uses the gmail app, popping up a 'appect' style dialogue.

Those options might not be available if you use a public terminal, and that's an issue, but somewhat orthoganal to the SC. If the site is providing appropriate options for the users then it has fulfilled the SC.

[patrickhlauke]

of course you "could" use lots of other alternatives. my point is that not every site/author can do this easily/implement this. but they'll have to if this SC makes other options illegal.

[alastc]

At the small-scale level you've got email-reset loops, and simply marking up username/password properly so it works with browser-based password managers.

At the larger-scale level where you're implementing 2FA, then yes there are certain options to include.

[patrickhlauke]

Those options might not be available if you use a public terminal, and that's an issue, but somewhat orthoganal to the SC

not really. it would mean that if a site that is meant to be accessed on those terminals, it will not be able to pass this SC (and therefore fail WCAG at Level A). while technically that is not "Web Content" in that scenario perhaps (but more a closed system), it would prevent these types of systems from being WCAG compliant.

At the small-scale level you've got email-reset loops

reset loops don't seem to be covered/approved in the understanding. only direct email login links (a different thing) seem to be mentioned.

and simply marking up username/password properly so it works with browser-based password managers.

correction: email and password, it seems. and yes that aspect needs to then be more fully explained in the understanding doc, as per #1363

[patrickhlauke]

to go a bit on a tangent, i find it weird that on the one hand, we had a discussion last time around that "it would be too onerous to require websites to implement responsive design" when discussing reflow. on the other here, we're mandating potentially quite complex alternative authentication solutions to be rolled out (unless you're suggesting/the SC implies that passing https://www.w3.org/TR/WCAG21/#identify-input-purpose - if that's what "properly marked up" means - will suffice. but then the simplest option to pass is the least secure (if the other options that escalate security further are then not allowed unless even more complex ones are put in place)

[SteveALee]

I will check further. but for now

• surely autofill is effectively programmatic cut n paste so should be fine in a command line environment. If autofilling password managers choose only to work with GUIs thats another matter. I'm not sure I follow the exact point in the original comment.
• "so disabling copy/paste is terrible." Terrible and misguided "full stop" in IMHO - not just for cognitive accessibility. The NCSC agree
• but whether copy and past should officially be sanctioned as a "pass" is not clear to me. I don't recall discussing it.
• My recollection was "Transcription" means things like "give me the 1st 5th and 10th character of your password". I agree it needs a clear definiton as it is not obvious

@lseeman @rachaelbradley @JohnRochfordUMMS may have comments

[extra808]

external one-time-passcode things (e.g. 6 digits changing every 30 secs) would be [a fail.]

At one point, such hardware was the solution for two-factor authentication (2FA). Have security experts with knowledge of practices and regulations internationally confirmed that 2FA providers have, and are permitted to use, alternate methods (like the MS Authenticator app's "yes" button)?

[smhigley]

I don't really feel qualified to comment on how onerous this would be overall, particularly for smaller-site developers, since auth isn't really a field I'm experienced in :).

With this specific issue, my goal was just to cover non-2FA bases where autofill is not available. Command line interfaces are one example that exists on the web, but we also have other potential scenarios on e.g. desktop apps where autofill also does not exist. I doubt allowing copy/paste would solve every possible scenario, but it would at least solve a few of the specific ones we were able to think of that might otherwise have no path to compliance.

@SteveALee you wrote:

surely autofill is effectively programmatic cut n paste so should be fine in a command line environment. If autofilling password managers choose only to work with GUIs thats another matter. I'm not sure I follow the exact point in the original comment.

I don't believe it would ever be possible for browser autofill or a password manager to work with a CLI, since there is no mechanism to programmatically expose the nature of the current prompt. The prompt for an ssh passphrase, or username/password is going to look exactly the same to a browser as the generic command prompt.

It is probably worth noting that if copy/paste is allowed, the wording in the Understanding doc about correctly marked up email/password fields as referenced in #1363 could be removed, since "correct" input type isn't required for copy/paste to work. It would still be covered by 1.3.5 though, so I'm not sure anything would be lost.

[jake-abma]

still wondering about copy/paste.

As far as I remember we've talked about examples for retrieving password and I thought the general idea was to not allow the "we send you a (new) password" and you have to transcribe it into the password field, but to send an email with a link where you get logged in automatically.

The technique made based on this is: https://www.w3.org/WAI/WCAG22/Techniques/general/G218

If copy/paste is allowed, this opens up lot's of possibilities like sending a password and people just have to cope/paste it (no cognitive function test needed (?!))

My memory might be wrong but we've discussed this at least twice.

[jake-abma]

Also, when copy / paste is allowed, is it allowed when the the following is possible:

"We send you a (temporary) password via SMS to your mobile, you can copy and paste it into your email application, send yourself a email, copy it from your email and paste it into your password field in your Web browser, you're all set to go"

This as an example of possibilities when copy/paste is allowed.

[alastc]

Noting #1292 is essentially the same question, with a slight variation for User Agent assistance.

[alastc]

There are some platforms and environments where autofill is not possible, such as a web-based command line interface where authentication is text-only, with no GUI controls or other options.

That’s a good point, our focus has been on more typical login flows, and copy-paste has been considered in terms of password managers.

The definition of a cognitive function test includes transcription, but it isn't entirely clear if the ability to copy and paste a string is a passing method.

There is some reluctance for a general ‘pass’ on copy-paste, as there are various scenarios where it can be a massive hindrance/blocker.

For example, having multiple steps to get from one app to another within 30 seconds is a blocker, even if you are copy-pasting rather than transcribing.

Also, it is difficult to predict the user’s scenario. A 2FA app with timed-codes on a second device (e.g. phone app) when you are using a desktop browser is then transcription rather than copy-paste.

If we can find a way of saying this: “Copy paste is ok if it is a two step method (copy from one place, and one-step to paste into the input), but not ok if you have more steps.” That seems like a good place to be.

I believe, though I may be wrong, that "transcription" in that definition https://www.w3.org/TR/WCAG22/#dfn-cognitive-function-test was alluding not to things like 2FA fobs, text messages, etc.

It was intended to put one-time-codes in scope, but there is some grey area because in some cases you have to transcribe, in others you can copy-paste.

if all those things (2FA etc) are essentially "outlawed" by this SC, i'd say it's exceedingly draconian for a level A...

Let’s keep the draconian discussion in #1364, it’s next on my list.

If copy/paste is allowed, this opens up lot's of possibilities like sending a password and people just have to cope/paste it (no cognitive function test needed (?!))

That’s going to fail any security audit though, as the passwords should not be retrievable like that.

"We send you a (temporary) password via SMS to your mobile, you can copy and paste it into your email application, send yourself a email, copy it from your email and paste it into your password field in your Web browser, you're all set to go"

That’s what I mean about the multiple steps aspect. Whilst technically it “allows” copy-paste, that process is effectively a ‘puzzle’.

[alastc]

How about adding to the transcript line in the definition?

E.g.

transcription, such as typing in characters. Copy and paste, such as that automated by a password manager, is not considered transcription but requiring multiple steps or applications to complete a paste is a cognitive functional test;

NB: I'm not trying to say that multiple applications should be covered, but requiring multiple steps & applications in order to paste is an issue.

I also added this to the intent in a branch:

Copy and paste can be relied on in simple cases to avoid transcription. Example of this are password managers automatically filling in username and passwords, or web-based command line interfaces asking for a password that can be copied from a local source.

[patrickhlauke]

but requiring multiple steps or applications to complete a paste is a cognitive functional task

I assume you mean it's a cognitive functional test, and here i'd disagree. also, multiple applications ... you mean more than two? or more than one? e.g. 1password (running as full application) and the browser ... would THAT fail?

[alastc]

Sorry, I did mean test (updated). Are you disagreeing about switching between multiple applications is a CFT, or that is how we should define the scope?

Password managers don't require you to leave the application, the controls are within the browser (or keyboard on iOS, I suspect Android is similar). In the web-based command-line case I assume you'd have to switch to one other application and then back, but the 'content' is not setting up a situation where you have to paste from email or SMS etc.

[SteveALee]

Password managers don't require you to leave the application, the controls are within the browser (or keyboard on iOS, I suspect Android is similar).

In my case I usually get a popup offering to fill from lastpass password manager in firefox

Usually needs an extra biometric figure print check but that might be configurable.

[patrickhlauke]

In my case I usually get a popup offering to fill from lastpass password manager in firefox

because you have the extension installed in firefox. so it's not directly built-in. this starts to fudge things. Some browsers may not offer an extension/direct integration with a particular password manager that runs as a separate app. But that's not under the author's control.

Usually needs an extra biometric figure print check but that might be configurable.

if the device you're on allows it. similarly on my Surface I can authenticate with fingerprint or camera for 1Password, but on my desktop machine I need to unlock 1Password by typing an actual password. again, not something controlled by the author.

[patrickhlauke]

Are you disagreeing about switching between multiple applications is a CFT

yes, it seems to stretch the idea of "test" a bit ... "I'm testing to see if you're able to switch applications". maybe the word "test" here is not quite right? I assume here's it's more about something that causes a cognitive load, rather than something that tests cognitive abilities. and, as pointed out, it is likely outside of the author's control to know whether there's a built-in or 3rd party password manager or authenticator app running.

[SteveALee]

because you have the extension installed in firefox

No, not on Android.

I guess I was saying if it is done via keyboard like iOS the UI presents quite differently.

On desktop lastpass firefox extension adds an icon to edit controls

[patrickhlauke]

No, not on Android.

I assume then that there's perhaps a Lastpass app installed on Android that hooked itself into the system-level keyboard or similar? It doesn' happen by default on Firefox/Android, at least not for me.

[alastc]

Hi everyone,

As an update, this was discussed in the meeting today. There was general agreement to allow for copy-paste, realizing that it does open some complex authentication methods, but that is mostly out of the author's control.

The associated branch will have the current change reverted, and some explanation will be added to the understanding document for copy-paste examples.

[alastc]

I've made an update to the branch. It isn't normative, but does this clarify things enough @smhigley?

Preview (last paragraph of the intent).

[smhigley]

This seems clear to me, and resolves my initial concern :). Thanks again to everyone for discussing and working on this!

[mraccess77]

For copy/paste to be acceptable is there any other requirements as well that must be met in tandem such as support for autocomplete, etc. Just asking for clarification. It seems like it would have to be something that would be on the same system unless you can use a hand off app to copy from mobile to pc. Macs support iMessage on the mac so you could argue a text message could be copied from SMS to a website on Mac.

[alastc]

For copy/paste to be acceptable is there any other requirements as well that must be met in tandem such as support for autocomplete, etc.

Have a look at the latest understanding doc where the first example is:

A web site uses a properly marked up username (or email) and password fields as the login authentication (meeting Success Criterion 1.3.5 Input Purpose and Success Criterion 1.3.1: Info and Relationships). Copy & paste is not blocked on the inputs, so the user's browser or extension can identify the purpose of the inputs and automatically fill in the username and password.

When it comes to cross-application copy-paste I don't think we can separate undesirable scenarios from desirable ones, given our scope of the web site/application. For a web page, if it allows copy-paste then it does allow it.

[patrickhlauke]

Even though this is now closed, can I just ask ... the whole thing about multiple applications/switching between them to copy/paste. Is that now allowed or not? e.g. if I try to log in, but the site does a "we'll send you a code by email"...and I have to switch from browser to email client, copy the code from the email, then paste it into the webpage ... is that acceptable?

[alastc]

Yes. It fits into the same category as the paste-to-command-line issue that was raised. When assessing a web-page, it shouldn't block the pasting.