Password Security and Password Manager Guide

Passwords are still the most common way people sign in, and still the most common way attackers get in. Reused, guessed and stolen passwords power credential stuffing, password spraying and most account takeovers, and shared passwords for admin and service accounts quietly undermine accountability. The rules have also changed: NIST SP 800-63B-4 now tells organisations to stop forcing periodic changes and complexity rules, and to focus on length, breached-password screening and rate limiting instead. This guide sets out modern password policy, how password attacks work, how to store and screen passwords, where password managers fit, and how to shrink the number of passwords you depend on.

Key takeaways

• Length and screening beat complexity and expiry. Require long passwords, check them against breached and common lists, and only force a change when there is evidence of compromise.
• Credential stuffing and spraying are volume attacks. Rate limiting, bot defence and MFA stop them far better than stricter rules.
• Store passwords with a slow, salted, memory-hard hash, never reversibly.
• Password managers reduce reuse but concentrate risk. Protect the manager itself with phishing-resistant MFA.
• Shared passwords belong in a vault with checkout and rotation, or better, replaced with individual or federated access.

Modern password policy

NIST SP 800-63B-4, published in 2025, sets requirements that many regulators and auditors now use as a reference point:

Forced rotation and complexity rules push people towards predictable patterns, such as a season and year with a trailing symbol, which attackers guess first. Length plus screening produces passwords that are both easier to remember and harder to crack. Check sector rules too: some frameworks and older internal policies still require rotation, and you may need to document why you have moved away from it.

How password attacks work

• Credential stuffing: automated login attempts using username and password pairs leaked from other services, relying on reuse. The 23andMe breach started with stuffing into accounts without MFA.
• Password spraying: a few common passwords tried against many accounts, staying under lockout thresholds. The Midnight Blizzard breach began with a spray against a legacy account.
• Infostealers: malware that collects saved browser passwords and session cookies from endpoints, including personal devices used for work. Infostealer credentials were central to the Snowflake customer breaches.
• Phishing: fake sign-in pages that capture the password, often with a real-time relay for one-time codes.
• Offline cracking: guessing against stolen password hashes, which is why the hashing algorithm matters.
• Synced and personal storage: work passwords saved to personal browser profiles or accounts. In the Cisco 2022 breach a VPN password had been synced to a personal Google account.
• Passwords in code and configuration: database, SMTP and service passwords in repositories, pastes and config files. See the Secrets Management Guide.

Defending sign-in

• Screen at set and at use: reject breached and common passwords when they are chosen, and act when a user's current password appears in a new breach corpus.
• Rate limit and detect automation: throttle per account, per IP range and per device, and use bot detection for customer logins. See the Identity Fraud Prevention Guide.
• Add MFA, preferably phishing resistant. See the MFA Guide.
• Do not leak which part was wrong: give the same response for an unknown username and a wrong password.
• Watch for spraying: failures spread thinly across many accounts from related sources are a spray, even if no single account locks.
• Block legacy protocols that allow password-only authentication.

Storing passwords

• Use a password hashing function designed to be slow and memory-hard. The OWASP Password Storage Cheat Sheet recommends Argon2id, with scrypt, bcrypt or PBKDF2 as alternatives where Argon2id is not available.
• Use a unique salt per password, and consider a secret pepper held outside the database.
• Never store passwords with reversible encryption or a fast general-purpose hash.
• Plan how to re-hash to stronger parameters over time, typically at the next successful sign-in.

Password managers

Password managers let people use a unique, long password for every site, which removes the reuse that credential stuffing depends on. They also autofill only on the matching domain, which gives some protection against look-alike phishing pages.

• Enterprise vs personal: provide an enterprise password manager with central policy, recovery and offboarding rather than leaving staff to use personal ones.
• Protect the vault: the master credential and the manager's own account are high-value targets. Require phishing-resistant MFA and monitor for new device enrolment.
• Understand the provider's risk: the LastPass 2022 breach showed that encrypted vault backups can be stolen, leaving the strength of each master password as the last line of defence.
• Keep secrets for machines out of human password managers: API keys and service credentials belong in a secrets manager with access control and rotation.

Shared and privileged passwords

Shared passwords break accountability, because nobody can tell which person used them, and they rarely change when people leave.

• Replace shared accounts with individual accounts and role-based or just-in-time elevation where possible. See the JIT Access Guide.
• Where a shared credential is unavoidable, such as a local administrator, keep it in a privileged vault with checkout, session recording and rotation after use.
• Rotate local administrator passwords per machine, for example with Windows LAPS, so one cracked password does not unlock every host. See the Active Directory and Entra ID Hardening Guide.
• Keep break-glass passwords long, sealed and monitored. See the Break-Glass Account Guide.

Service account passwords

Service accounts with passwords are frequently long-lived, over-privileged and excluded from MFA. Where the platform supports it, use managed service accounts or workload identity instead of a password. Where it does not, use long random passwords held in a vault, rotate them automatically, deny interactive sign-in and monitor use. See the Service Account Security Guide.

Reducing the number of passwords

• Put applications behind single sign-on so staff hold one strong credential rather than dozens.
• Move people to passkeys where applications and devices support them. See the Passwordless and Passkeys Guide.
• Replace machine passwords with federated, short-lived credentials. See the NHI Authentication Guide.
• Keep a password as a fallback only where there is no better option, and secure the recovery route. See the Account Recovery and Help Desk Security Guide.

Practitioner checklist

• Update password policy to length-based rules with no composition requirements and no scheduled expiry.
• Screen new and existing passwords against breached and common password lists.
• Rate limit sign-in and detect spraying and stuffing patterns.
• Enforce MFA, and block legacy protocols that accept a password alone.
• Hash stored passwords with Argon2id or an equivalent slow, salted algorithm.
• Provide an enterprise password manager protected by phishing-resistant MFA.
• Vault shared and privileged passwords, rotate them after use and rotate local admin passwords per machine.
• Remove passwords from code, configuration and tickets, and replace service account passwords with managed or federated identities where possible.

Standards and references

• NIST SP 800-63B-4: Authentication and Authenticator Management (2025)
• OWASP Password Storage Cheat Sheet
• OWASP Credential Stuffing Prevention Cheat Sheet
• UK NCSC password guidance
• Windows LAPS overview

Related NHI Mgmt Group resources: MFA Guide · Passwordless and Passkeys Guide · Workforce Identity Security Guide · Secrets Management Guide