Autocomplete for passwords is discouraged for security concerns (WCAG 2.1 Success Criterion 1.3.5)

[RababGomaa]

Issue Use of Autocompete autocomplete="on" attribute is described as a technique to meet 1.3.5 ref. Using HTML 5.2 autocomplete attributes

From security perspective, Autocompete is treated like browser-based passwords managers which are considered a security concern. ref Password Managers-Security (ITSAP.30.025) . The risk is higher for protected B material. Therefore, web teams are discouraged from using autocomplete and consequently the are failing on meeting WCAG 2.1 1.3.5.

On the other hand, use of user password managers that require two‑factor authentication is a security recommendation. However, two‑factor authentication has many ways of application and none is recommended for accessibility.

(Suggested labels : 1.3.5 Input purpose, WCAG 2.1)

Recommendation

• Evaluation of two factor authentication for user password fields for accessibility and recommend a method that works for people with disability and provide it as a WCAG technique.
• Consultation with ITSecurity teams would ensure that the technique in discussion is in alignment with security. With this, development teams will have two options to choose from to satisfy WCAG 1.3.5

fyi - Discussion happening within the Government of Canada, Digital Accessibility Toolkit WCAG 2.1 Success Criterion 1.3.5: Identify Input Purpose: Passwords #54

CC @shawnthompson

[mraccess77]

Personally speaking - my browser and password managers suggest to fill fields regardless of the use of autocomplete or not. They even suggest on fields with autocomplete off.

[patrickhlauke]

@mraccess77 they'll use heuristics, which can't be relied on as a universal solution.

regarding ITSAP and the mention of 2-factor authentication, i'd note that the reference there is to have a password manager that requires 2-factor, and not that the site itself use 2-factor.

[mraccess77]

@patrickhlauke Yes - my point is that SC 1.3.5 is not introducing more of a security issue then already exists today with browsers and password managers.

[patrickhlauke]

ah, gotcha. yes agree, even if a form field has explicit autocomplete=off this can be overridden by password managers anyway

[alastc]

I'm not quite picking up the logical step from:

Autocompete is treated like browser-based passwords managers which are considered a security concern. ref Password Managers-Security (ITSAP.30.025)....

To:

Therefore, web teams are discouraged from using autocomplete and consequently the are failing on meeting WCAG 2.1 1.3.5.

It seems to be mixing up advice for sys-admins / corporate IT and advice aimed at website creators.

Autocomplete is what you put on the website, and you can't tell what password manager (if any) the user has.

Browser based password managers might be a problem (although I'd argue better than nothing on a locked-down corporate laptop), but that doesn't impact whether someone uses autocomplete on a website.

I couldn't see anywhere on cyber.gc.ca that was saying you should not allow for password managers on the content side, it was how IT should protect password managers. The UK equivalent is positive about them.

The bottom line is that we can't require people/organisations to require 2-factor on user-agents (password managers), we are scoped to web-content.

Evaluation of two factor authentication for user password fields for accessibility and recommend a method that works for people with disability and provide it as a WCAG technique.

We do have a new success criterion which covers accessible use of 2-factor as part of WCAG 2.2: accessible authentication.

Consultation with ITSecurity teams would ensure that the technique in discussion is in alignment with security.

We did a review with the W3C security group as part of 2.1, and will again for 2.2, that is partly where the information Shawn pointed to came from.

[patrickhlauke]

yup, agree with @alastc - the advice is all about the security of the password manager itself, rather than whether a site should allow/try to block use of password managers (as mentioned above about the 2-factor being about the password manager itself, and not something a site should implement)

[shawnthompson]

I really think this is a fight we need to have with ITSec within the Government of Canada. For years it's been a struggle with us (Accessibility) versus them (IT Security), when we should be working together.

As a person with a cognitive disability, I rely on my form / password fillers on the web and can't live without them. Not enough spoons to remember all my passwords or even my address for that matter.

[patrickhlauke]

ITSec does appear to be slightly confusing matters in the https://cyber.gc.ca/en/guidance/password-managers-security-itsap30025 document there, but just re-reading it to make sure they are indeed talking about the two-factor for the password manager (or so it seems)

Two-factor Authentication For an extra layer of security, we recommend using password managers that require two‑factor authentication.

So I don't think, from a reading of just that document, that they're saying anything that goes against what WCAG says (as WCAG is not concerned with the password manager part of the equation here)

(for reference/as example, password managers like Bitwarden do provide two-factor authentication to unlock/access a password vault https://bitwarden.com/help/article/setup-two-step-login/ and that's what that ITSec document makes reference to)

[wpcoc]

I have noticed this potential issue recently, although it hasn't directly affected my team yet. Working on WCAG support for one product, I can see autocomplete is recommended for passwords (new-password and current-password). But for another product that recently underwent a penetration test, the presence of an autocomplete attribute caused a low-severity flag to be raised on the pentest report (example detail). Sadly, we have to favour the security report over the accessibility guidelines, especially due to the mentioned possible knock-on impact on PCI compliance, so there is no opportunity for discussion on this for us. I'm hopeful that an agreement can be reached with regards to this issue. In the meantime, I can only hope that the relevant accessibility tools will still operate as expected when faced with password fields with autocomplete="off"

[patrickhlauke]

Coming back to this, I would respectfully argue that the pentest flag is misguided. Trying to force users (by trying to prevent their browsers from not offering to store login credentials) not to use password managers (be they built-in, or integrated into their browser through extensions) does nothing other than forcing users to either choose weaker passwords they can remember, or at the very least cause inconvenience and friction.

The throwaway claim at the end that attackers may be able to then somehow compromise the browser's password storage is FUDdy as well. If an attacker manages to inject a cross-site script into a login page, they'll get the password either way ... either when it's autocompleted, or when the user actually enters it manually to log in.

[nattarnoff]

@wpcoc Allowing autocomplete on passwords IS security. While there is the chance they could get hacked, the alternative is a user who can't easily paste a secure password inn will have to rely on another person to do it. If they are lucky, it is someone they trust. If not, then security is VERY compromised. Not to mention, not allowing it is a violation of WCAG 2.2 SC 3.3.8 Accessible Authentication (Minimum).

[wpcoc]

@patrickhlauke thank you for your considered reply. I happen to agree with you that the pentest flag is misguided. On the point about password managers, I believe you are spot on - the risk of disabling autocomplete features promotes poor password practices. The same concern extends to related features, such as the ability to paste into the field, although fortunately paste was not flagged by the pentest result. The references provided by @RababGomaa point to guidance for users about how to improve the security of their password managers - encouraging the use of managers with MFA enabled, for example, but the issue there is not the browser's autocomplete option per se. A browser implementing MFA on their autocomplete for passwords would be fine, for example.

With regards to your point about FUD, I agree that once "an attacker... gains control over the user's computer" (referencing the terminology used in the pentest documentation), this would most likely compromise security in other ways. At that point, the presence of lack thereof of autocomplete seems largely irrelevant to security. There seems to be no clear justification for disabling autocomplete. However, sadly, we are still expected to adhere to the pentest result.

I'm glad I commented here, but I feel this Github issue can probably be closed and the focus should be on overturning the pentest recommendations!