Password Security and Password Manager Guide

Passwords are still the most common way people sign in, and still one of the most common ways attackers get in. Reused, guessed and stolen passwords power credential stuffing, password spraying and most account takeovers, while shared passwords for admin and service accounts quietly undermine accountability. The rules have also changed: NIST SP 800-63B-4, finalised in July 2025, tells organisations to stop forcing periodic changes and composition rules and to rely on length, blocklists and rate limiting instead. This guide covers policy, attacks, sign-in defences, storage, password managers, shared and service account passwords, and how to depend on fewer passwords. It is written for identity architects, security engineers, application developers and the teams who own workforce and customer sign-in.

Key takeaways

• Length and screening beat complexity and expiry. NIST SP 800-63B-4 requires at least 15 characters for single-factor passwords, forbids composition rules and periodic changes, and requires a blocklist check whenever a password is set.
• Stuffing and spraying are volume attacks. Rate limiting, bot defence, monitoring across accounts and MFA stop them far better than stricter password rules.
• Store passwords with a slow, salted hash. OWASP recommends Argon2id first, with scrypt, bcrypt or PBKDF2 where it is not available; never encrypt passwords reversibly.
• Password managers reduce reuse but concentrate risk. NIST says verifiers shall allow them; protect the manager's own account with phishing-resistant MFA and keep machine secrets out of it.
• Shared and service passwords need a different model. Vault them with checkout and rotation, rotate local admin passwords per device, and replace machine passwords with managed or federated identities wherever the platform allows.

Modern password policy

NIST SP 800-63B-4 is written for US federal systems, but regulators, auditors and many private-sector policies use it as the reference point. Its password section (Sec. 3.1.1) sets these positions, which our Password Policy Template turns into policy wording:

The reasoning is in the standard's appendix: users respond to composition rules in predictable ways, so "password" becomes "Password1", and those patterns are what attackers guess first. The UK NCSC reaches the same conclusion, saying regular password changing "harms rather than improves security" and that complexity requirements "provide no defence against common attacks". Instead, the NCSC suggests effective movers and leavers processes, locking inactive accounts and monitoring logins for suspicious behaviour.

• Write down why you changed: some sector rules, contracts and older internal standards still demand rotation. Record the NIST and NCSC rationale and the compensating controls (blocklist, rate limiting, MFA, monitoring) so auditors see a decision, not a gap.
• Help users choose: the NCSC suggests machine-generated passwords held in a password manager, and "three random words" for passwords people must remember.

How password attacks work

Most password compromise involves reuse, guessing at scale, theft from endpoints or tricking the user, not cracking. MITRE ATT&CK tracks the guessing techniques under Brute Force (T1110), including Password Spraying (T1110.003) and Credential Stuffing (T1110.004), and theft from storage under Credentials from Password Stores (T1555), which includes browsers and password managers.

• Stuffing at scale: according to the joint investigation by the UK ICO and the Privacy Commissioner of Canada, the 23andMe Breach 2023 ran for five months, included more than one million login attempts in a single day, and succeeded against accounts where fewer than 22 percent of customers used MFA or single sign-on.
• Quiet spraying: in the Microsoft Midnight Blizzard Breach 2024, Microsoft says a password spray compromised a legacy non-production test tenant account without MFA, using a low number of attempts through residential proxies to avoid detection. ATT&CK also records a variant that tried a single sign-in per 24 hours.
• Infostealer credentials: Mandiant says at least 79.7 percent of the accounts used in the Snowflake Breach 2024 had prior credential exposure, mainly in infostealer logs, and that the accounts lacked MFA and had not been rotated for years. See the Infostealer Threat Guide.
• Synced personal storage: in the Cisco Breach 2022, Cisco Talos says an employee's credentials were saved in the browser and synchronised to a personal Google account the attacker controlled.

For attack-level detail and response, see the Password Spraying and Credential Stuffing Guide.

Defending sign-in

The OWASP Credential Stuffing Prevention Cheat Sheet calls MFA "by far the best defense" against password attacks, and lists layered alternatives where MFA cannot reach everyone.

Screen and throttle

• Screen at set and at use: check new passwords against a blocklist (NIST requires it), and re-check existing passwords when new breach corpuses appear. Have I Been Pwned's Pwned Passwords range API accepts only the first five characters of a SHA-1 or NTLM hash (k-anonymity), so the password itself is never sent; the full hash set can also be downloaded for offline use.
• Add organisation terms: Microsoft Entra Password Protection applies a global banned list to every tenant and allows a custom list of up to 1,000 base terms such as brand, product and location names, with variants blocked automatically.
• Throttle rather than lock: NIST allows bot challenges, growing delays between attempts (for example 30 seconds up to an hour) and risk-based signals. The NCSC prefers throttling because lockout enables denial of service, and suggests 5 to 10 attempts if you do use lockout.

Make automation expensive

• Bot and device signals: OWASP lists CAPTCHA for suspicious requests, device and connection fingerprinting, requiring JavaScript, multi-step login and IP intelligence, noting that toolkits rotate through proxy networks to defeat per-IP limits. See the Bot Management Guide and the Identity Fraud Prevention Guide.
• Do not leak which part was wrong: OWASP's Authentication Cheat Sheet says login, password reset and recovery must return a generic error whether the user ID or password was incorrect, to prevent user enumeration.
• Block legacy protocols that accept a password alone, and require MFA on every internet-facing system. See the MFA Guide and the Phishing-Resistant MFA Guide.

Storing passwords

NIST requires passwords to be stored "in a form that is resistant to offline attacks": salted and hashed with a password hashing scheme that takes a cost factor, with a salt of at least 32 bits and a record of the scheme and cost so you can migrate later. It also recommends an extra keyed hash using a secret key stored separately, ideally in a hardware security module. The OWASP Password Storage Cheat Sheet gives current minimum parameters:

• Pepper with care: OWASP says a pepper must be stored separately from the password database, for example in a vault or HSM, and that changing it forces affected users to reset, so plan the key lifecycle first.
• Upgrade work factors at sign-in: the common approach is to re-hash with new parameters the next time a user authenticates; hashes of users who never return stay weak, so set a deadline after which they are reset.
• Never use reversible encryption or a fast hash such as MD5 or SHA-1 for passwords, and periodically search systems for passwords held in plain text, as the NCSC advises.

Password managers

Password managers let people use a unique, long password for every site, which removes the reuse that credential stuffing depends on. NIST notes they increase the likelihood of stronger passwords, especially with a built-in generator, and the NCSC recommends them for secure storage wherever appropriate. Autofill only on the matching domain also gives some protection against look-alike phishing pages.

• Enterprise, not personal: provide an enterprise password manager with central policy, recovery, sharing controls and offboarding, rather than leaving staff to use personal tools or browser profiles that sync to personal accounts.
• Protect the vault: the master password and the manager's own account are high-value targets. Require phishing-resistant MFA, alert on new device enrolment and review trusted-device settings.
• Understand the provider's risk: in the LastPass Breach 2022, a keylogger captured a senior DevOps engineer's master password, the ICO says MFA was bypassed with a trusted device cookie, and backups of customer vault data were copied, leaving each customer's master password as the last line of defence.
• Keep machine secrets out: ATT&CK lists password managers as a target in T1555.005. API keys, database passwords and service credentials belong in a secrets manager with access control, audit and rotation. See the Secrets Management Guide.

Shared and privileged passwords

Shared passwords break accountability, because nobody can tell which person used them, and they rarely change when people leave. The NCSC advises delegation instead of sharing wherever possible; where sharing remains necessary, keep the group small, hide the password from people without permission, and change it when someone loses access.

• Replace shared accounts with individual accounts and role-based or just-in-time elevation. See the JIT Access Guide.
• Vault what remains: where a shared credential is unavoidable, keep it in a privileged vault with checkout, approval, session recording and rotation after use. See the Privileged Access Management Guide.
• Rotate local administrator passwords per device: Microsoft notes local administrator accounts "often share the same password across many devices", which attackers exploit to move laterally. Windows LAPS rotates and backs up each device's password to Active Directory or Microsoft Entra ID. See the LAPS Guide and the Active Directory and Entra ID Hardening Guide.
• Separate admin and daily accounts and change all default vendor passwords before deployment, as the NCSC advises.
• Seal break-glass passwords: keep them long, stored offline or in a sealed vault, excluded from routine use and alerted on every sign-in. See the Break-Glass Account Guide.

Service account passwords

Service accounts with passwords are frequently long-lived, over-privileged and excluded from MFA, and their passwords end up in scripts, configuration files and tickets.

• Prefer passwordless machine identity: use group managed or delegated managed service accounts on Windows, and managed identities or workload identity federation in the cloud, so no human ever handles the secret. See the NHI Authentication Guide.
• Where a password is unavoidable: generate it long and random, store it in a vault, rotate it automatically, deny interactive sign-in and alert on use outside the expected hosts. See the Service Account Security Guide.
• Give every account an owner and a lifecycle: creation, review and decommissioning dates belong in the inventory. See the NHI Lifecycle Management Guide.
• AI agents and automation: agents and scripts that log in to legacy systems with a stored password inherit every weakness above, plus the risk that the password appears in prompts, logs or tool output. Give each agent its own identity and short-lived credentials brokered at run time, and never paste a human's password into an agent's configuration.

Reducing the number of passwords

The NCSC's first tip is to reduce reliance on passwords: use them only where needed and appropriate, and consider single sign-on, hardware tokens and biometrics. Every password removed is one less to phish, reuse or leak.

• Single sign-on: put applications behind SSO so staff hold one strong credential rather than dozens, and protect that credential with phishing-resistant MFA, because the NCSC warns a compromised SSO account opens far more.
• Passkeys: move people to passkeys where applications and devices support them. See the Passwordless and Passkeys Guide.
• Secure the fallback: keep a password only where there is no better option, and secure the recovery route, which attackers target once passwords are strong. See the Account Recovery and Help Desk Security Guide.

Detection and monitoring

Password attacks are noisy in aggregate but quiet per account. MITRE's detection strategy for password spraying (DET0487) looks for authentication failures using one password or a small set across many accounts in a time window, across SSH, SSO and SaaS, mailboxes, network devices and container control planes. The NCSC adds failed second MFA steps, logins from unexpected locations and unexpected lockouts reported by users.

• Correlate across accounts: count failures per source and per password pattern, not just per user.
• Watch the protocols that bypass MFA: LDAP, Kerberos and legacy mail protocols are named by ATT&CK as less likely to trigger high-visibility events.
• Treat success after failures as an incident signal: a correct password followed by an MFA denial, or a sign-in from a new device after a spray, warrants a forced reset and session revocation.
• Feed breach and infostealer intelligence into resets. See the Leaked Credential Response Playbook.

Framework mapping

This is an indicative alignment prepared by NHI Mgmt Group, not an official mapping by any framework owner. Control IDs were checked against the NIST CSF 2.0 text, the NIST SP 800-53 Rev. 5 catalogue and a published ISO/IEC 27001:2022 Annex A list; CIS Controls v8.1 are given at control level.

IA-5(1) in SP 800-53 Rev. 5 now mirrors the NIST guidance: maintain and check a list of commonly used, expected or compromised passwords, store passwords with a salted key derivation function and allow long passwords and passphrases.

Common failure patterns

• Old rules left in place: 90-day expiry and complexity rules remain because "the auditor expects it", producing seasonal patterns that sprays guess first.
• Short minimums on customer sites: regulators found 23andMe passwords needed only eight characters with minimal complexity, and monitoring could not detect anomalous behaviour.
• MFA everywhere except one place: a legacy test tenant, an old VPN or a mail protocol accepts a password alone, as in the Midnight Blizzard spray.
• Credentials never rotated after exposure: infostealer logs held passwords that still worked years later in the Snowflake campaign, because nobody matched exposures to accounts.
• Corporate passwords in personal stores: browser sync to a personal account handed the attacker a working VPN password at Cisco.
• Machine secrets in human vaults: cloud storage keys held in an individual's password vault turned one engineer's home computer into the LastPass backup theft.

Metrics that show progress

Implementation roadmap

Practitioner checklist

• Set a minimum of 15 characters for single-factor passwords, allow at least 64, and remove composition rules and scheduled expiry.
• Check every new password against a blocklist, explain rejections, and re-screen existing passwords against new breach data.
• Rate limit sign-in with throttling and bot challenges, and detect spraying across accounts and sources.
• Enforce MFA, phishing resistant for admins, and block protocols that accept a password alone.
• Return generic errors on login, reset and recovery to prevent user enumeration.
• Hash stored passwords with Argon2id or another OWASP-listed algorithm at current parameters, with a separately stored pepper or keyed hash.
• Provide an enterprise password manager, allow paste and autofill, and protect the manager with phishing-resistant MFA.
• Vault shared and privileged passwords, rotate them after use, and rotate local admin passwords per device with LAPS.
• Remove passwords from code, configuration and tickets, and keep machine secrets in a secrets manager.
• Replace service account and agent passwords with managed or federated identities, each with an owner.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• OWASP: Password Storage Cheat Sheet
• OWASP: Credential Stuffing Prevention Cheat Sheet
• OWASP: Authentication Cheat Sheet
• UK NCSC: Password policy: updating your approach
• MITRE ATT&CK: T1110.003 Password Spraying
• MITRE ATT&CK: T1555 Credentials from Password Stores
• Microsoft: Windows LAPS overview
• Microsoft: Password protection in Microsoft Entra ID
• Have I Been Pwned: API documentation (Pwned Passwords)

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