Password Rules that are already defined using contraint validation attributes

[mnoorenberghe]

To avoid duplication and future conflicts between a quirk and the website rules I'm not sure Password Rules should be accepted in the repo if the rules match what the page's markup already indicates via constraint validation attributes e.g. via minlength, maxlength, pattern, etc. The requirements for many sites can be expressed with those constraint validation attributes without the use of passwordrules.

Is that already covered by the - [ ] The given rule isn't particularly standard and obvious for password managers checklist item in the PR? If so, maybe that should be more clear and documented in CONTRIBUTING.md as well.

[sp-magicspells]

@mnoorenberghe Can markup validation attributes cover all the password rules like max-consecutive? Is there a possibility that password managers has to combine rules from both validation attributes and passwordrules. In that case password managers can first look at the validation attributes and missing rules can be obtained from corresponding passwordrules.

[igor-makarov]

I think the idea is that if a website has defined password rules using markup, the quirk is unnecessary and should be removed.

[sp-magicspells]

@igor-makarov Yeah, sure understood. I was just thinking of one more possibility where websites have defined password rules using markup but some of them are missing so we cannot completely remove quirk but only remove already defined rules.

[igor-makarov]

@sp-magicspells I believe the likelihood of a website adding the rules incompletely is low.
Usually, the developers either care about password managers/required to care by contract - or - they don't care and there's no markup at all.

[Zegnat]

Is pattern really something password managers can use in any helpful way as a constraint?

I think it can only be used for validation: the password manager generates a password and checks it against the pattern. (This is also assuming the password manager can include a regular expression matcher that follows the JavaScript implementation of RegExp.) What is the password manager supposed to do when it does not match the pattern? Try again? What if it has failed to generate a matching one 100 times in a row?

Things like max-consecutive could be encoded into a pattern, but I do not think it should be up to the password managers to figure that out. It would be extremely hard for them to parse something like (\d)((?!\1)\d)((?!\2)\d)((?!\3)\d) and know that this means “4 digits, no consecutive”. From the web developer point of view this will Just Work™️ for in-browser validation, from the password manager developer point of view this will require a full reverse RegExp parser to figure out the constraints.

You can make some really complex patterns, and even use JavaScript to update them on the fly. Super dumb example:

const password = document.querySelector('input[type="password"]')
document.querySelector('input[name="first_name"]').addEventListener('change', name => {
  password.setAttribute('pattern', `(?!${name.target.value}).{4,}`)
})

This makes sure the user cannot use their name as their password. Browser validation for the win. But now password managers suddenly have to handle pattern changing?

That said, I am all for following rules that websites can add as specific markup, and I can definitely see why those would not have to be repeated within this project! It is just pattern I am very sceptical off.

[sp-magicspells]

@Zegnat Yes. I agree. I think password managers can prioritize the resources in here first and if not available then follow constraints in the markup and complex patterns. So that we can still continue adding such quirks. What is your thought on this @igor-makarov?

[igor-makarov]

I think password managers can be proactive about these things and this repo is sort of the last line of defense for websites that "didn't get the memo".

Also, a generated password has very low chance of hitting the odd quirks like "no consecutive" and it better not use the username! 😂

[Zegnat]

Sure, and I totally cop to having created dumb examples 😉

Just mostly wanted to highlight that pattern is not a very good replacement for something like this project’s max-consecutive, because I have a hard time imagining anyone wants to write a reverse JavaScript RegExp string parser to figure that stuff out.

Big 👍 to leveraging all information that can otherwise be extracted from a page’s DOM though!

[mnoorenberghe]

I said:

I'm not sure Password Rules should be accepted in the repo if the rules match what the page's markup already indicates via constraint validation attributes

I'm not suggesting that we should remove rules that aren't encoded in the attributes. max-consecutive is unlikely to be encoded in pattern but sites requiring that are also rare.

Is pattern really something password managers can use in any helpful way as a constraint?

Yes, using an algorithm like you suggested:

the password manager generates a password and checks it against the pattern.

What is the password manager supposed to do when it does not match the pattern? Try again?

Yes, ideally with different variants of lengths or character classes

What if it has failed to generate a matching one 100 times in a row?

Give up and maybe inform the user… that should be exceptionally rare if this password rules repo is used along with a good set of variants to try after the first failure.

But now password managers suddenly have to handle pattern changing?

I don't see that being a problem for most password managers which require user interaction before generating a password. They can delay generation until it's necessary.

I think password managers can prioritize the resources in here first and if not available then follow constraints in the markup and complex patterns.

Markup should ideally be preferred as it's likely less stale than this third-party repo.

In summary, it sounds like nobody disagrees with my original suggestion that we shouldn't merge password rules if they don't add value above what the markup attributes already indicate.

[rmondello]

In summary, it sounds like nobody disagrees with my original suggestion that we shouldn't merge password rules if they don't add value above what the markup attributes already indicate.

Yes. That’s why the README says this:

If a website changes its password requirements to be general enough to not warrant quirks, or if it adopts the passwordRules attribute to accurately communicate its requirements to password managers and web browsers, it should be removed from this list.