HTML: passwordrules attribute

[annevk]

In whatwg/html#3518 Apple engineers propose a new attribute for <input type=password> that'll assist password generators doing the right thing.

I'm personally enthusiastic about the idea.

(There's many small incremental features like this added to WHATWG standards. It's not quite clear to me if we want an issue for each of them, but we probably do want a Mozilla position on each of them, so... Filing this one as a test.)

[jonathanKingston]

"Restrictions on passwords beyond minimum length (and maybe a large maximum length) are all fundamentally bad" ... Do we really want to be adding a feature whose primary use-case is making it easier for already-broken sites to continue being broken?

Cementing this into a standard would somewhat agree with the status quo, I'm with Tab on this.

I had a proposal that merely permitted a site selecting the entropy which would restrict the length and also inform the password manager how long it should be safe to store. For example most sites aren't going to want a 50mb password but also a 50 character one might be overkill for a voucher token.

[linuxwolf]

On the one hand, I think it would be very helpful to get hints for what a site wants for passwords. It helps password generators come up with something for the user faster.

However, I think this proposal is moving in the wrong direction. As @jonathanKingston points out, it cements – even encourages – bad practices, without promoting good practices (e.g., minimum length).

My personal opinion would be we lean toward harmful on this.

[annevk]

I see some positives for sites with hard-to-change backends not thwarting password managers, but perhaps that's best catalogued in https://github.com/apple/password-manager-resources and not the frontend of those sites.

@linuxwolf are you interested in writing a PR for this, as nobody contested your comment and the one above?

[mnoorenberghe]

For the most part I agree with whatwg/html#3518 (comment) from Chromium but I also have some other concerns:

• While I find the use of <key>:<value>; more clear, it differs from syntax of CSP and feature policy. Would this be the first attribute that uses this syntax? Is it worth diverging from that prior art? @annevk had similar comments at Proposal: HTML passwordrules attribute whatwg/html#3518 (comment)
• The overlap with setCustomValidity and @pattern: Proposal: HTML passwordrules attribute whatwg/html#3518 (comment)
• This is likely to have low adoption and may encourage sites to add password requirements (as mentioned above too): Proposal: HTML passwordrules attribute whatwg/html#3518 (comment)

Without even taking into account ValidityState, our telemetry data shows that only 4% of generated passwords are edited after generation. That seems okay and I suspect only a small fraction of sites which rejected these generated passwords would even know to adopt this new attribute. (This telemetry mostly catches when sites do client-side validation before submission so the user knows to edit and may slightly under-count rejected passwords that are only caught on the server side.)

whatwg/html#3518 (comment) is the approach we were planning to take after supporting minlength/maxlength/pattern attributes (and possibly checking ValidityState.customError) so we don't have any plans to adopt this new passwordrules attribute. We will also use a list of recipes to override the generated password format for sites which don't use the constraint validation attributes but have unique requirements.

IMO this new attribute would be harmful if it encourages new password restrictions or if authors use it instead of minlength/maxlength/pattern/setCustomValidity, which are also useful outside of password generators.

[jrmuizel]

I'm not convinced that supporting the password rules attribute will actually encourage sites to add new password restrictions. It's hard to imagine a scenario where a develop wants to add restrictions but the developer cost for enforcing the restrictions is the bottleneck.

I think the potential user value during password generation and the ease of use by sites outweighs any potential downside here.

[zcorpan]

In 2023 the attribute had very low adoption: whatwg/html#3518 (comment)

It's possible it would be adopted more if there was cross-browser support and better docs. Some browsers have out-of-band site-specific password rules (e.g. https://github.com/apple/password-manager-resources/blob/main/quirks/password-rules.json ), which seems likely to continue to exist as long as websites have password restrictions and don't use the passwordrules attribute. But it seems reasonable to allow websites to specify their own rules to improve UX, even if adoption continues to be low.

[jrmuizel]

My suggestion is that our position be positive.

[issammani]

I agree with with @jrmuizel. I think the benefits outweigh any potential downsides. As @zcorpan stated with better docs and better support we can get some adoption going, although I think we will always need the pre-defined list as a fallback.