Enforce Minimum Password Strength Requirements

EMR currently accepts any password without enforcing strength requirements.

I was able to create a client team member account using a very weak password - abcdef01 - 6 letters + 2 digits, which registered as "Weak" on the Bitwarden password strength meter - https://bitwarden.com/password-strength/

EMR should enforce a baseline level of password strength across all user account types as this is now standard security practice everywhere with password strength meters now the norm and commonplace.

Current Behaviour

• Any password is accepted at account creation, regardless of length or complexity.

• No feedback is given to the user about password strength.

• No restrictions on commonly used or breached passwords.

Minimum Expected Behaviour

At minimum, passwords should be validated against a baseline policy before being accepted.

A reasonable starting point aligned with current NIST SP 800-63B guidelines would be the below:

Required

• Minimum length of 12 characters (NIST recommends 8 as minimum, 12+ is now considered best practice minimum).

• Reject passwords found in known breach lists (e.g. via the Have I Been Pwned "Pwned Passwords" API).

• Reject obvious weak patterns (e.g. password123, abcdef01, sequential or repeated characters).

Recommended

• Display a real-time strength meter during password creation to guide users.

• Allow long pass phrases, spaces, with the full ASCII/Unicode character set.

• Do not force complexity rules as current guidance has moved away from these as they tend to produce predictable patterns (Password1!) without meaningfully improving strength.

• Do not force rotation unless there's evidence of compromise.

This should apply consistently to all account types:

• Agency users

• Client users

• Team members

• Any admin or service accounts

Considerations

• Existing accounts: We should decide whether to

  • a) force a password reset on next login for accounts that don't meet the new policy or

  • b) prompt users to update at next login with a grace period.

• MFA: Strong passwords are only one layer. We should also have the option to force 2FA on user accounts too. This is an “optional” requirement as I know not many people are comfortable with 2FA but it is getting more widespread and Authenticator app is really easy to use. As I say - optional toggle perhaps.

• Passkeys: Another future option, passkeys are the future, easy, saved to password managers, iCloud keychain, Google Auth etc and are more and more widely used and can negate the whole password thing entirely. Optional and perhaps future implementation.

• Rate limiting & lockout: Ensure login endpoints are rate-limited to prevent brute-force attempts against any account. Need to decide on lock out time, 15-30 is usually the norm after 5 failed attempts or we then just rest password after these attempts.

• Storage: Confirm passwords are hashed with a modern algorithm not just SHA/MD5.

Why This Matters

Weak passwords are still one of the most common causes of account compromise. Given the platform handles agency and client data, a low-effort policy change here meaningfully reduces the risk of credential stuffing and brute-force attacks, and brings us in line with baseline industry standards.