Add security mention to Timing Adjustable and tweak Re-Authentication

[patrickhlauke]

• adds mention of security exceptions such as two-factor/MFA tokens (under "essential") for timing adjustable
• tweaks examples in re-authentication (they appear to violate timing adjustable at the moment) and cross-reference to timing adjustable

bonus:

• removes excessive whitespace (spaces, tabs, empty lines) from the two understanding docs
• replaces a <p><strong>...</strong></p> with actual heading markup
• replaces "spasticity" - while medically accurate, this ... just looks off

closes #1424
closes #3290

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	452056d
🔍 Latest deploy log	https://app.netlify.com/sites/wcag2/deploys/6818e31580fa7d00086494fa
😎 Deploy Preview	https://deploy-preview-4382--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mfairchild365]

This gives me some pause, as there are many kinds of MFA techniques and much nuance here. Some MFA techniques have standards that dictate timeouts. Others are less standardized. More importantly, I've been in many situations where very short (60 seconds or less) timeouts have been pushed by engineers for "security", but the timeout was really chosen arbitrarily ("shorter much be more secure - right?").

Timeouts this short can outright block people with certain disabilities from completing authentication. Some relevant standards include NIST Special Publication 800-63B and rfc6238. Generally speaking, my understanding is that:

• The 30 second timeout for a Time-based One-Time Passcode (TOTP) is RECCOMENDED by rfc6238, but not required. However, since it is such a common implementation, it would be very difficult to argue for something higher. That being said, the RFC also reccomends that the OTP remain valid for 2x the length of the time the code is displayed. So even if it disappears, you can still enter it within that period, and it may be accepted.
• Other MFA techniques, such as timeouts associated with biometrics, passwordless sign-in, non-TOTP one-time passcodes, etc, generally is allowed a max of a 10min TTL per 800-63B, and in practice I usually see it closer to 5min. My conversations with security experts have also confirmed that only after 5-10 minutes will the security of the authentication attempt be invalidated.

How about something like:

Certain time limits implemented for security reasons, such as time-based / time-limited two-factor authentication tokens or actions, can be considered essential, and can be exempt from this criterion as long as the timeout was not chosen arbitrarily. For example, a timeout of 30 seconds for Time-based One-Time passcodes is common and a minimum timeout for other time-limited two-factor authentication tokens or actions of 5-10 minutes is also common.

[patrickhlauke]

as long as the timeout was not chosen arbitrarily. For example, a timeout of 30 seconds for Time-based One-Time passcodes is common and a minimum timeout for other time-limited two-factor authentication tokens or actions of 5-10 minutes is also common.

however WCAG is not a security spec, and i'd be careful making pass/fail dependent on "knowing whether a timeout was chosen arbitrarily or not". an auditor is generally not in a position to determine that. an auditor that feels strongly that what an author/site has implemented is ridiculously too short can still fail it but be prepared for a discussion/argument.

perhaps tweaking the wording slightly from "are exempt" to "may be exempt" is in order though, without having to go into lengthy detail.

[patrickhlauke]

perhaps tweaking the wording slightly from "are exempt" to "may be exempt" is in order though, without having to go into lengthy detail.

done

[mfairchild365]

Thanks @patrickhlauke. Agree that WCAG is not a security spec, but it has to be balanced with security. As you mention, a WCAG auditor is (likely) not a security SME, and thus won't be able to make an informed decision about when the essential exception for timeouts like these kicks in. I see a lot of "well, engineering says it's for security, so it's exempt", but a lot of that has little to no basis in reality or evidence to back it up - it's just being too cautious at the cost of blocking people with certain disabilities. I'm lucky enough to work in a large company with security SMEs that I can consult with on stuff like this, but others are not so lucky.

I'm saying this because I do think there is opportunity (and need) for some sort of documentation to help a WCAG auditor make an informed decision here. That sort of documentation / recommendation should have a cross-discipline participation though. That's likely a whole other project tho.

[mbgower]

As per the two issues that this PR attempts to address, I think there is general agreement that a timed authentication process meets the intent of the essential exception, especially one that follows a published security spec:

The time limit is essential and extending it would invalidate the activity

If authors are following their company's security policy, and that company has adopted a specification that stipulates time limits, that seems entirely sufficient to me for the exception. It seems unreasonable to put the burden on the author to prove the spec is essential. From the author's viewpoint, the company's security protocol is what they have to follow; it is the essential factor. (I'm talking from an enterprise perspective here, as opposed to a situation where the author has some degree of autonomy to decide the security protocols used.)

If someone believes an existing standard's time-out policy is unnecessarily or unnecessarily short, -- or feels that a standard's timeout should able to be extended 20 times -- that feels like an issue that should be opened against the security standard. Or I guess an issue could be opened against AGWG, specifying the standard under question, and allowing the chairs to escalate to the w3c or whomever.

[mfairchild365]

@mbgower - I understand. For established standards and policies where this is clear - I agree. However, the language of this modification was broad enough to cover situations that may not be covered by security standards or policy - and that's where I keep running into blockers for people with disabilities. Not all timeouts for security are essential.

Again, I'm okay with the current wording, but I do think it may be too vague to be very helpful.