Skip to main content

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.

4 comments

Log in to comment and vote

Comments4

  • mannie@embedmyreviews.com

    Team•

    May 18

    Pinned

    @Daniel Fawcett

    Thanks for raising this.

    You’re right that password hardening is a valid security improvement, and we already agree with the general direction here.

    A few points for clarity:

    EMR already supports 2FA, but currently leaves it optional because many agencies and client users are not yet comfortable with mandatory 2FA across all accounts. That said, we do see value in adding an agency-level option in the future to require 2FA for team members.

    On passwords, we agree that accepting very weak passwords is not ideal. We will review the current password validation rules and look at introducing a baseline policy that follows modern guidance: longer passwords/passphrases, no forced complexity rules, support for spaces/long passwords, and blocking obviously weak/common patterns.

    The likely approach would be:

    • Apply stronger password validation to all new accounts and password changes

    • Avoid old-style forced complexity rules such as mandatory symbols/uppercase

    • Allow long passphrases

    • Add clearer feedback during password creation

    • Review breached/common password checks

    • Review login rate limiting and lockout behaviour

    • Confirm hashing configuration is using a modern Laravel-supported hashing algorithm

    For existing users, we would need to be careful. Forcing every existing user into an immediate reset could create unnecessary friction, so a softer approach such as applying the rule on next password change or prompting users over time is probably more appropriate unless there is evidence of compromise.

    So yes, this is a valid hardening item and we’ll add it to our security improvements list. It’s not something we’d treat as a critical platform issue, especially with 2FA already available, but it is a sensible baseline improvement.

    • Daniel Fawcett

      •

      May 18

      Great to hear. When we are storing and processing customer data and their customers data it is needed to have proper security protocols in place esp for passwords.

      Option for enforcing 2FA would be great for team members, the general public are still a bit averse in my experience and I expect many would move to passkeys once that is more widely adopted.

      For existing users you can leave as is for now so there is no forced change - Perhaps there could be an email template that could be sent out telling users they have 30/60/90 days to change their password due to a “system upgrade” or something and after that if they have not then force a password reset. Could be set up like a campaign.

      This gives plenty of notice for all users, and also brings everyone up to the new standard and security level.

      I agree, it’s not critical but it should probably be high up the task list as we never know when an attack could come and with customer’s PII potentially stored it could be a serious issue.

  • Daniel Fawcett

    •

    Jun 26

    Any updates on this @mannie@embedmyreviews.com ?

  • Daniel Fawcett

    •

    May 18

    We cannot enforce 2FA on client accounts so this still issue remains and current security practices I believe fall short of industry standards and current bear practice guidelines