Properly tagged autocomplete attributes for Sign-In / Register forms

I would like to suggest that proper autocomplete attribute tags be added to the sign-in and registration forms in OJS. One cue is that Chromium now provides the following in the console when visiting an OJS journal:

[DOM] Input elements should have autocomplete attributes (suggested: "current-password"): (More info: https://goo.gl/9p2vKq) 
<input type=​"password" class=​"form-control" name=​"password" id=​"passwordModal" value maxlength=​"32" required>​

The practice of adding machine-readable autocomplete tags (such as for the username and new/current password fields) makes the platform more accessible and following best practices. This allows the browser to support the user in creating a more secure password and saving it.

For example, I’ve added the current-password tag to the end of this input. This tells the browser that this is a current password instead of a new password. Simple enough.

<input type=​"password" class=​"form-control" name=​"password" id=​"passwordModal" value maxlength=​"32" required autocomplete="current-password">​

The power then rests with the user if they wish to disable browser-based autocomplete at the client side. Right now, the fields aren’t properly tagged so you get irrelevant suggestions. Please see below for resources from the Chromium project on this matter. I’m curious to hear if there are any reasons why these attributes weren’t added so far, or if they could be added in the future. I could also submit a pull request if this is preferable.

https://web.dev/sign-in-form-best-practices/
https://www.chromium.org/developers/design-documents/create-amazing-password-forms

Thanks @benaltair! We’ve added several autocomplete tags as part of our accessibility efforts. These changes will go out with the next major version, 3.3, due to be released in early February.

These tags were added where accessibility concerns were at stake. Could you review the additions added as part of Add autocomplete fields to registration and login forms. · Issue #5185 · pkp/pkp-lib · GitHub? If there are additional tags that you think should be added that were not included in that work, please file an issue for us or consider submitting a PR with the proposed chages.

Great to see it in an upcoming release. I’ll file an issue on GitHub as the password fields could also be tagged. Thanks Nate.

I don’t think this is a good idea :
When you enable auto-complete with a password field, scan security tools detect and signal a vulnerability issue ( medium severity)
autocompete
What do you think @asmecher?

For what it’s worth, I see this as an example of security being looked at with an inappropriate scope. Zooming out, the larger question is about the side effects of not allowing autocomplete. This results in users reusing weak passwords.

Besides, if either the server or the users computer are already compromised, this is not the vector I’d be worried about for a password breach.

Autocomplete increases security by allowing password managers to fill in longer random passwords. Eventually we won’t even have passwords, as the industry moves to alternative authentication methods.