In general, I agree with the approaches Dropbox and GitHub both take. Dropbox's "zxcvbn" tool, however, hasn't been updated in years and has some odd bugs that are unlikely to be fixed. (For example, it doesn't count 2021 as a "recent year".) Meanwhile, GitHub allows eight-character passwords, which is too short.

Ideally, authentication should be moved to a third party, like Auth0 or Okta. In the meantime, these are my current recommendations for improving password requirements.

• Password requirements must be easy for the user to understand.
• It's okay to only show the basic rules at the start and reveal unspoken rules when necessary. For example, show the minimum length up front, but if a password is rejected based on another rule, then display a help message with more info.
• Password rules should be evaluated in real time on the web page with immediate feedback and also evaluated on the server on form submit.
• The following rules vary in programming complexity, but can be implemented incrementally in this order:
  1. Minimum length of 12 Unicode characters.
  2. Prohibit the password from containing the URL, app name, & user email or segments thereof.
  3. Compare the password to HIBP's common password list (reference code).
  4. Once the above are all implemented, we can remove the complexity requirements (i.e., uppercase, lowercase, and number).
• The rules should be applied to new passwords, but existing accounts shouldn't be forced to update.
• It makes sense to implement this as a separate API which can be called from any app from both front end and back end. (See GitHub's implementation.)

To clarify the HIBP step above: I'm proposing we prohibit a password if the count returned by the API > 100.

Management has expressed interest in moving auth to an external vendor such as Auth0 (now owned by Okta).