Passwords are still the most common way systems decide who someone is, and the most common thing attackers guess, crack and spray. D3-PWA Password Authentication is the MITRE D3FEND countermeasure for doing that check well: D3FEND defines it as "a security mechanism used to verify the identity of a user or entity attempting to access a system or resource by requiring the input of a secret string of characters, known as a password, that is associated with the user or entity." It sits in the Harden tactic as a child of Agent Authentication and uses the Password artefact. This card covers what a well-built password verifier looks like, which ATT&CK techniques D3FEND relates it to, how to test it and where it stops helping. It is written for identity engineers, application owners and detection teams. For policy settings, see the Password Policy Guide (NIST-aligned).
Key takeaways
- D3-PWA is about the verifier, not the user. Length rules, blocklists, attempt limits and hash storage are what decide whether a password check resists attack.
- NIST SP 800-63B-4 sets the current baseline. At least 15 characters for single-factor use, no composition rules, no forced periodic change, a blocklist check and a limit on failed attempts.
- D3FEND relates it to brute force and account techniques. The mapping runs through the Password and User Account artefacts, so read it as "relevant to", not "blocks".
- Storage decides the cost of a breach. A salted, slow password hash turns a stolen database from a list of logins into a cracking project.
- A password alone is single-factor. For anything externally reachable or privileged, D3-PWA is the first factor of MFA, not the whole control.
D3-PWA at a glance
| Field | D3-PWA Password Authentication |
|---|---|
| D3FEND ID | D3-PWA |
| Tactic | Harden |
| Parent technique | Agent Authentication (siblings include Biometric, Certificate-based, Multi-factor and Token-based Authentication) |
| Digital artefact | Password (D3FEND: the technique "uses" a Password); D3FEND's site also shows the User Account relation, which the parent strengthens |
| D3FEND reference | NIST SP 800-53 Rev 5 |
| What it changes | How the system accepts, checks, throttles and stores memorised secrets |
| Typical implementation points | Directory services, identity providers, application login code, network device and appliance local accounts, database authentication |
| Typical data sources for verification | Authentication success and failure logs, lockout and throttle events, password change events, hash format in the credential store |
| Main limitation | A correct stolen or reused password passes every check |
| Related ATT&CK mitigation | M1027 Password Policies |
What a strong password verifier does
NIST SP 800-63B-4 (final, 31 July 2025, superseding SP 800-63B) gives the most specific public requirements for password verifiers. The table summarises section 3.1.1.2 and the throttling rule in section 3.2.2.
| Requirement | SP 800-63B-4 position | Why it matters |
|---|---|---|
| Minimum length | At least 15 characters when the password is the only factor; at least 8 when used only within MFA | Length is the main driver of guessing resistance |
| Maximum length | Should allow at least 64 characters; verify the full password without truncation | Allows passphrases and password manager output |
| Composition rules | Shall not be imposed | Mixing rules produce predictable substitutions |
| Periodic change | Shall not be required; force a change on evidence of compromise | Scheduled changes lead to small, guessable variations |
| Blocklist | Check the whole password against commonly used, expected or compromised values at creation and change, and tell the user why it was rejected | Stops the passwords attackers try first |
| Failed attempts | Limit consecutive failures; no more than 100 per authenticator on an account by default | Bounds online guessing |
| Password managers | Must allow password managers and autofill; should allow paste | Makes long unique passwords practical |
| Hints and security questions | Hints for unauthenticated claimants and knowledge-based prompts are not permitted | Both leak or replace the secret |
| Storage | Salted (at least 32 bits) and hashed with a suitable password hashing scheme at a cost as high as practical; should add a keyed step with the key held separately | Raises the cost of offline cracking after a breach |
The NCSC's guidance for system owners points the same way: no regular expiry, no complexity rules, a deny list of common passwords, and throttling in preference to lockout. Where lockout is used, it suggests allowing between 5 and 10 failed attempts. See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide and Breached password checks.
Storing passwords
The OWASP Password Storage Cheat Sheet gives working parameters. Its examples are minimums to tune upwards on your own hardware, not fixed standards:
| Algorithm | OWASP minimum configuration | When to use |
|---|---|---|
| Argon2id | 19 MiB memory, 2 iterations, parallelism 1 | Preferred choice |
| scrypt | N=2^17 (128 MiB), r=8, p=1 | Where Argon2id is not available |
| bcrypt | Work factor 10 or more; inputs limited to 72 bytes | Legacy systems |
| PBKDF2 | 600,000 iterations with HMAC-SHA-256 (220,000 with HMAC-SHA-512) | Where FIPS-140 validated implementations are required |
A pepper (a secret key applied to all hashes and stored apart from the database, for example in a vault or HSM) is defence in depth, matching NIST's keyed-step recommendation. Fast unsalted hashes, reversible encryption and legacy formats such as LM or unsalted MD5 are what make cracking easy. See the Hashing Guide.
ATT&CK techniques D3FEND relates to D3-PWA
Relationship type: inferred only. D3FEND marks these relationships as inferred and experimental (checked November 2026). They come from two artefacts: D3-PWA uses Password, which T1110.001, T1110.002 and T1110.003 access; and the Agent Authentication parent strengthens User Account, which the account techniques act on. The last column is NHI Mgmt Group's assessment, not part of D3FEND. IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What a strong verifier changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1110.001 | Password Guessing | Accesses Password | Strong: attempt limits and blocklists bound online guessing |
| T1110.003 | Password Spraying | Accesses Password | Strong where blocklists remove the common passwords sprays rely on; per-account limits alone are evaded by low-and-slow sprays |
| T1110.002 | Password Cracking | Accesses Password | Partial: slow salted hashes raise cost; weak passwords still fall |
| T1078.001 to T1078.004 | Valid Accounts: Default, Domain, Local, Cloud | User Account sub-artefacts | Partial: helps against guessed passwords; no effect on reused or phished ones |
| T1098.002, T1098.003 | Additional Email Delegate Permissions, Additional Cloud Roles | User Account sub-artefacts | Indirect: protects the accounts used to make the change |
| T1136.001 to T1136.003 | Create Account: Local, Domain, Cloud | User Account sub-artefacts | Indirect: new accounts inherit verifier rules if policy applies at creation |
| T1548.005 | Temporary Elevated Cloud Access | User Account sub-artefact | Indirect |
| T1087.001, T1087.002, T1087.004 | Account Discovery: Local, Domain, Cloud | User Account sub-artefacts | Minimal: discovery feeds spraying lists |
| T1531 | Account Access Removal | User Account | Indirect: strict lockout can itself be abused to lock users out |
The D3FEND ontology also links the Password artefact to the ATT&CK for ICS technique Default Credentials, under an ID ATT&CK has since revoked; its v20 successor is T1694.001 Default Credentials. See the MITRE ATT&CK T1110 Brute Force Guide and M1027 Password Policies.
Where it is implemented
| Enforcement point | What to configure | Typical gap |
|---|---|---|
| Directory services | Minimum length, banned password list, lockout or throttling thresholds, modern hash formats | Legacy hash formats or reversible encryption kept for old applications |
| Identity provider | Password rules, breached password detection, smart throttling, MFA after the password step | Fallback local login paths that skip the provider's protections |
| Custom application login | The SP 800-63B-4 verifier rules and an OWASP-recommended hash in code | Home-grown hashing, truncation, or silent maximum lengths |
| Network devices and appliances | Unique local passwords, central authentication where available, management restricted to admin networks | Vendor defaults left in place |
| Databases and middleware | Native password policy features and strong hash storage for built-in accounts | Shared application accounts with passwords that never change |
Where identity and NHIs fit
D3FEND's definition covers "a user or entity", and many non-human identities still authenticate with passwords: service accounts, database logins, application pool identities and device local accounts. These cannot use MFA prompts, are often excluded from lockout to avoid outages, and rarely meet the rules applied to people. Give them long random passwords held in a vault and rotated by it, or move them to certificate or token-based authentication. See the D3-PR Password Rotation and the D3-CDP Change Default Password.
Implementation steps
- Inventory password verifiers. List every system that checks a password itself, including appliances and custom applications, and note its length rules, attempt limit and hash format.
- Fix storage first. Move weak hash formats to a recommended algorithm. Rehash on next successful login, and force resets for accounts that never log in.
- Add a blocklist. Check new and changed passwords against common and breached values, and audit existing hashes against the same list where the platform allows.
- Change the policy in report mode where possible. Raise minimum length and remove composition and expiry rules, communicating the change before it applies at next password change.
- Tune attempt limits. Prefer throttling; if lockout is used, set thresholds that stop guessing without letting an attacker lock out every user. Test with a pilot group and keep the previous threshold documented for rollback.
- Put MFA after the password. For external, cloud and privileged access, treat D3-PWA as the first factor. See the D3-MFA Multi-factor Authentication.
- Move non-human accounts. Vault and rotate service account passwords, or replace them with stronger authentication.
How to verify it works
- Policy tests: try to set a 14-character password, a password from the blocklist and a 64-character passphrase with spaces. The first two should be refused with a reason; the last accepted in full.
- Attempt-limit test: with a test account, confirm throttling or lockout triggers at the configured threshold and is logged.
- Storage audit: confirm the hash format in each credential store, and look for any plain-text or reversibly encrypted passwords. NCSC advises periodically searching systems for plain-text credentials.
- Authorised cracking audit: with approval, run a cracking exercise against a copy of the hash store to measure how many passwords fall to common wordlists. See the Hashcat and Password Cracking for Defenders Guide.
- Detection: confirm alerts for spraying patterns: many accounts failing with few attempts each, from one source or a proxy network. On Windows, failed logons appear as event ID 4625. See the D3-ANET Authentication Event Thresholding.
| Metric (examples, not standards) | What it shows | Target direction |
|---|---|---|
| Verifiers meeting the length and blocklist rules | Policy coverage | Rising to 100% |
| Credential stores using weak or legacy hash formats | Exposure if a store is stolen | Zero |
| Share of hashes cracked in an authorised audit | Real password strength | Falling each cycle |
| Spray patterns detected and triaged | Detection coverage for T1110.003 | All reviewed within normal triage time |
| Password-only (single-factor) external sign-ins | Where D3-PWA stands alone | Falling toward zero |
Limits, bypasses and failure patterns
- Single factor on a forgotten account: in the Microsoft Midnight Blizzard Breach, a password spray from residential proxies compromised a legacy non-production test tenant account that had no MFA. Low-volume sprays stay under per-account lockout, so password checks need MFA and tenant-wide spray detection beside them.
- Reused passwords: a password stolen elsewhere is correct, so verifier rules do not help. Breached password checks and MFA do.
- Lockout as a weapon: aggressive lockout lets an attacker lock out users at will, which ATT&CK's M1036 guidance for spraying warns against.
- Old hash formats kept for compatibility: one legacy application can keep weak hashes alive for every account.
- Help desk resets: a strong verifier is undone if a reset can be obtained with a phone call.
- Hash reuse inside the network: protocols that accept a hash instead of the password make storage strength irrelevant once a host is compromised. See the Pass-the-Hash and Pass-the-Ticket Guide.
Framework mapping
| Framework | Reference | Relationship to D3-PWA |
|---|---|---|
| MITRE ATT&CK | M1027 Password Policies | Mitigation for the brute force sub-techniques D3FEND relates to D3-PWA |
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management | Password-based authenticator requirements (control enhancement IA-5(1)) |
| NIST SP 800-53 Rev 5 | IA-2 Identification and Authentication (Organizational Users) | Authenticating users before access |
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware are authenticated |
| NIST SP 800-63B-4 | Section 3.1.1 Passwords | Verifier requirements summarised above |
Related countermeasures
- Password hardening siblings: D3-SPP Strong Password Policy, D3-PR Password Rotation and D3-CDP Change Default Password all act on the same Password artefact.
- Stronger authenticators: D3-MFA, D3-OTP One-time Password and passkeys reduce reliance on the password. See the Passwordless and Passkeys Guide.
- Response to guessing: D3-AL Account Locking and D3-ANET Authentication Event Thresholding act when guessing is detected.
Practitioner checklist
- List every system that verifies passwords itself, including appliances and custom code.
- Require at least 15 characters for password-only access and allow at least 64.
- Remove composition rules and scheduled expiry; force change only on evidence of compromise.
- Check new and changed passwords against a blocklist of common and breached values.
- Limit failed attempts, preferring throttling, and alert on spray patterns across accounts.
- Store passwords with Argon2id, scrypt, bcrypt or PBKDF2 at tuned cost, with a separately held pepper where practical.
- Allow password managers and paste.
- Put MFA after the password for external, cloud and privileged access, and vault service account passwords.
Standards and references
- MITRE D3FEND: Password Authentication (D3-PWA)
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- NCSC: Password policy, updating your approach
- OWASP: Password Storage Cheat Sheet
- MITRE ATT&CK: T1110.003 Password Spraying
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Password Policy Guide (NIST-aligned) · Account Lockout and Brute-Force Protection Guide · D3-MFA Multi-factor Authentication · MITRE ATT&CK T1110 Brute Force Guide · MITRE D3FEND Guide