Account Protection: Add custom password strength meter

[dkmyta]

Description

Replaces the core password strength meter UI—found in password management UIs (add new user, update profile, and password reset forms)—with a branded Jetpack strength meter that applies a custom set of password validation rules. We can enqueue our own JS to run on top of the core validation (using its set as an additional check) and our set to further harden to validation process without needing change the form submission flow or any major core functionality.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

• https://github.com/Automattic/jetpack-scan-team/issues/1642
• https://github.com/Automattic/jetpack-scan-team/issues/1640

Does this pull request change what data or activity we track or use?

• No

Testing instructions:

• Checkout this branch using JT
• Load Protect or Jetpack and enable Account Protection
• Attempt to:
  • Create a new user - /wp-admin/user-new.php
  • Edit an existing user (not your current user) - /wp-admin/user-edit.php?user_id=<user_id>
  • Edit your user - /wp-admin/profile.php
  • Reset your user password - /wp-login.php?action=lostpassword
• Ensure the password input detects in invalid password and that you are able to effectively bypass the warnings

Screenshots

profile.php (user-specific):

new-user.php (non user-specific):

edit-user.php (non user-specific):

action=rp || action=resetpass (non user-specific):

[nateweller]

I can see how it can get complicated here surrounding accessing the state of the core password strength meter on the client side, maintaining that integration, etc.

It feels fragile to depend on the class name of a DOM element, but I understand there are probably limitations here.

I wonder if checking the current presence of the insecure password acknowledgement checkbox on the page would be any better? Edit: It does look like the short bad good strong classes used by core is the best indicator we have.

Zooming out a bit as well, it would be great to give more context re: the "passes core validation" checkbox. If core does not provide any "why", perhaps we could have the password strength meter status mimic cores as a final fallback, and remove the "passes core validation" item entirely. WDYT?

[dkmyta]

I thought about this one quite a bit and went and back and forth on it.

The original idea was to make every effort to not modify or remove anything that core does currently, and instead hook into the current validation process and add our custom conditions on top so we can continue to use other related core functionality (eg. auto population, showing/hiding the field) and keep the original form submission handling clean.

It's not ideal, but the only obvious way I found to verify the success of the core validation was to check the class. Checking for the presence of the acknowledgement could work, but then it might get more complicated when our own conditions trigger it to hide or show.

I'll note that the core validation does appear to run a number of unique checks so I do think keeping it could be valuable. Unfortunately, there is no explanation provided when the core validation fails.

If we leave the core validation handling intact but don't include it in our set, things external to core strength meter continue to happen (eg when core validation fails the insecure password acknowledgement checkbox displays, submit button is disabled, etc). It might seem awkward if all our checks pass but core doesn't and the validation is green but they are still prompted to check the bypass to be able to submit.

[nateweller]

It might seem awkward if all our checks pass but core doesn't and the validation is green but they are still prompted to check the bypass to be able to submit.

In the case where the core validation is the failing check, we could mirror the status in our status bar.

We wouldn't necessarily need to remove the checklist item, maybe it is just the "Passes core validation" label that I am worried about. It is a lot of jargon. WDYT of just labeling it "Strong password"?

[dkmyta]

I think that makes sense to me, the current label is pretty ambiguous. We could also only display it if its failing, similar to the backslashes item? Do you think we should modify the tooltip or is that reasonable as is?

[dkmyta]

Only possible issue with hiding it initially is that our checklist conditions look pretty limited when were on a form that has no user specific checks run (create, edit other user, reset):

Maybe that's fine though, not constantly overwhelming the user with info.

[nateweller]

Aside - the core #pass-strength-result uses aria-live="polite", I wonder if we should use that attribute for ours as well?

[dkmyta]

@nateweller Thanks for the thorough review - I've applied the requested changes.

I've also documented some minor UI awkwardness to address in follow-up/clean-up tasks (if timing permits) here: https://github.com/Automattic/jetpack-scan-team/issues/1710