Password Security

Trick 1 Length vs. Complexity — The Math the Exam Uses Against You

The exam presents a comparison between a short complex password and a long simple one and asks which has more entropy. Most test-takers intuitively pick the complex password. The correct answer is almost always the long one.

The entropy formula: combinations = character_set_size^length

8-character password using full character set (94 chars): 94⁸ ≈ 6 × 10¹⁵ combinations
16-character lowercase-only password (26 chars): 26¹⁶ ≈ 4.4 × 10²² combinations
The 16-character lowercase password has 7 million times more entropy despite using far fewer character types

Why this is counterintuitive: adding a character type (e.g., going from 26 to 94 characters) multiplies by about 3.6×. Adding one character to the length multiplies by the entire character set size. Each length increment compounds exponentially; each character set increment is a one-time multiplier.

NIST connection: NIST SP 800-63B favors passphrases over complexity rules for this exact reason. A 4-word passphrase beats an 8-character complex password in entropy every time.

Rule: Length multiplies by the full character set each time. Character set expansion is a one-time flat multiplier. Long always beats short-and-complex in entropy. NIST: passphrase > P@ssw0rd1!

Trick 2 Credential Stuffing — What Stops It (and What Doesn't)

The exam will describe a scenario where credentials stolen from Site A are used to log into Site B, C, and D, and ask which control prevents this. The correct answer is always a password manager (unique passwords per service), not MFA, not complexity requirements, not expiration.

Why MFA alone is wrong: credential stuffing does not bypass MFA. But the question asks specifically what prevents credential stuffing. Unique passwords eliminate the attack at the source — if every site has a different password, a breach at Site A yields a credential valid only at Site A. MFA is a mitigation; unique passwords prevent the attack entirely.

Why complexity and expiration are wrong:

A complex password reused across sites is just as vulnerable to stuffing as a simple one
Expiration does not help if the attacker tests the credential immediately after a breach — and most credential stuffing attacks are automated and fast

Password manager logic chain: password manager → unique random password per site → breach at Site A exposes only Site A's credential → credential useless at Sites B, C, D → credential stuffing attack fails

Rule: Credential stuffing = reuse attack. The only preventive control is unique passwords per service. Password manager generates and stores unique passwords. MFA mitigates but does not prevent. Complexity and expiration are irrelevant to stuffing.

Trick 3 JIT vs. Vaulting — The Two Questions That Separate Them

The exam presents a scenario and asks whether JIT permissions or password vaulting is described. Most candidates mix them up because both involve privileged access. Two diagnostic questions instantly separate them:

Question 1: Does the credential expire?

If YES → JIT permissions (ephemeral credentials with a TTL)
If NO → Password vaulting (permanent credentials rotated by the vault)

Question 2: Does the administrator know the password?

If YES (even temporarily) → JIT permissions
If NO (vault proxies the session, admin never sees the credential) → Password vaulting

Exam trap scenarios:

“Credentials issued for a 2-hour maintenance window” → JIT (time-limited)
“Administrator connects to the database server and the session is recorded; administrator does not know the database password” → Vaulting (session proxy, hidden credential)
“Request submitted, approved by clearinghouse, temporary elevation granted” → JIT (clearinghouse = JIT workflow component)
“Credentials automatically rotated after each checkout” → Vaulting (auto-rotation is a vaulting feature)

Rule: JIT = temporary + admin may know it. Vaulting = permanent + admin NEVER sees it. Clearinghouse = JIT. Session proxy = Vaulting. Auto-rotation = Vaulting. TTL/expiration = JIT.

Trick 4 Passwordless Authentication — Identifying the True Factor Combination

The exam asks what makes Windows Hello (or a similar passwordless system) true MFA when there is no password involved. Candidates who answer “it is just something you are” or “it uses biometrics only” are wrong.

The Windows Hello factor breakdown:

Biometric scan (face or fingerprint) = something you are
TPM chip holding the private cryptographic key = something you have

The biometric unlocks the TPM-protected key. Authentication is performed by the key, not the biometric. The private key never leaves the TPM — this is why remote credential theft fails even if the password database is breached (there is no password to breach).

The MFA qualification: two different factor categories are satisfied: inherence (biometrics) + possession (TPM). This is true MFA without any password.

Why “just biometrics” is wrong: the TPM is the authenticating component. The biometric is the local unlock mechanism for the TPM key. Without the physical device (TPM), the biometric alone cannot authenticate — the combination is required.

Passwordless also prevents: phishing (no password to phish), credential stuffing (no credential to stuff), brute-force (no password hash to crack), and password reuse attacks.

Rule: Windows Hello = biometric (something you are) + TPM key (something you have) = true MFA with no password. The TPM does the authentication; biometric unlocks the TPM. Remote credential theft impossible: private key never leaves TPM.

Practice Scenarios

Scenario A: A security team is evaluating password policy changes for a 2,000-person organization. The current policy requires passwords with uppercase, lowercase, numbers, and special characters, minimum 8 characters, changed every 90 days, with no password history enforcement. The team is considering two alternatives: Option 1 — keep complexity rules but extend minimum length to 16 characters and enforce 24-password history. Option 2 — eliminate complexity rules entirely, require minimum 16-character passphrases, block passwords found in breach databases, and remove expiration for accounts with MFA. Which option better aligns with NIST SP 800-63B, and what specific weakness does each option address or leave unaddressed?

Answer: Option 2 better aligns with NIST SP 800-63B. Here is the analysis: Option 1 analysis: Extending length to 16 characters is correct and substantially increases entropy (26^16 ≈ 4.4×10^22 combinations for a hypothetical lowercase-only example vs. 94^8 ≈ 6×10^15 for an 8-character complex password). Adding 24-password history prevents cycling. However, retaining complexity rules perpetuates predictable patterns: users with 16-character requirements will create things like “Password123!” extended to “PasswordPasswordPW!” or pad existing patterns. Enforcing 90-day expiration continues to drive weaker choices. This option solves the length problem but not the predictability problem. Option 2 analysis: Eliminating complexity rules removes the pressure that produces predictable character substitutions. Requiring passphrases aligns with NIST guidance (accept up to 64 characters, support passphrases like “correct horse battery staple”). Blocking breached passwords via deny-list (checking against databases like Have I Been Pwned) is explicitly recommended in NIST 800-63B. Removing expiration for MFA accounts addresses NIST's observation that frequent expiration produces weaker passwords without security benefit when MFA compensates for credential compromise. Option 2 addresses both entropy (length) and predictability (no complexity patterns, breach check). What Option 2 does not address: it relies on the breach database being up-to-date; a newly breached but not-yet-indexed password passes the check. Password history is not mentioned, so Option 2 as described may allow passphrase reuse. The team should add a history check (at least 5-10 previous passphrases) to complete the policy.

Scenario B: A financial services firm uses a privileged access management (PAM) system. An auditor identifies three specific workflows and asks the security architect to classify each as JIT permissions, password vaulting, or both: (1) A DBA requests access to the production database server. The PAM system validates a change ticket and issues a temporary database credential valid for 4 hours. The DBA uses this credential to log in directly. (2) A system administrator connects to a Windows server via the PAM console. The PAM system injects the local Administrator password into the session; the administrator sees a desktop but never sees or receives the password. The password is automatically changed after the session ends. (3) A cloud engineer needs elevated IAM permissions in AWS. The PAM system creates a temporary IAM role with the required permissions for 2 hours; the role automatically expires. The engineer does not receive a password — they assume the role via their existing identity. For each workflow, identify the control type and explain the classification.

Answer: Workflow 1 — JIT Permissions: The PAM system validates a request (clearinghouse function), issues temporary credentials (ephemeral), with a defined TTL (4 hours). The DBA receives and uses the credential directly — they know it. The credential expires automatically. This is JIT: temporary credential, admin may know it, time-bounded elevation. It is NOT password vaulting because the admin receives and uses the credential directly rather than the vault proxying the session. Workflow 2 — Password Vaulting: The administrator never sees the password — the vault injects it invisibly into the session (session proxy). The credential is permanent (it exists indefinitely, not created for this session) and is rotated automatically after each checkout. The administrator sees a connected session but no credential. This is pure password vaulting: hidden credential, session proxy, automatic rotation, persistent account. Workflow 3 — JIT Permissions (not password vaulting): A temporary IAM role is created with a 2-hour TTL. This is ephemeral elevation with automatic expiration — the defining characteristic of JIT. However, there is no password involved and no session proxying. The engineer authenticates with their own identity and assumes a role. This is role-based JIT (common in cloud environments via AWS STS/AssumeRole). Vaulting is not applicable because there is no privileged credential to vault — the role itself is the ephemeral access grant. Summary: Workflow 1 = JIT (temporary credential, admin knows it). Workflow 2 = Vaulting (permanent credential, admin never knows it, session proxy). Workflow 3 = JIT (ephemeral role, no credential involved). The key differentiator is whether the admin receives/knows the credential (JIT) or the vault hides it behind a proxy (vaulting).

Scenario C: A technology company is migrating from traditional username/password authentication to passwordless authentication for all 500 employees. The CISO proposes Windows Hello for Business for laptop users and FIDO2 USB security keys for users who work on shared workstations. The IT director raises three objections: (1) “Windows Hello is just biometrics — that is only one factor, not MFA.” (2) “If an employee's facial recognition is compromised, we can just reset the biometric like we would a password.” (3) “FIDO2 keys are a single point of failure — if someone loses their key, they cannot authenticate anywhere.” Evaluate each objection: is it technically correct? If incorrect, explain the error. If correct, explain the risk mitigation.

Answer: Objection 1 — Incorrect: Windows Hello for Business is true MFA despite having no password. The IT director is applying a definition of MFA that equates to “must include a password,” which is not the correct definition. MFA requires two or more factors from different categories. Windows Hello combines: (1) facial recognition = something you are (inherence factor) and (2) a private cryptographic key stored in the TPM chip = something you have (possession factor). The biometric unlocks the TPM-protected key; the TPM performs the actual authentication via challenge-response. Two different factor categories are satisfied. This is MFA. The private key never leaves the TPM, meaning even if an attacker obtains the biometric scan, they cannot authenticate without the physical device containing the TPM. Objection 2 — Incorrect: The IT director is confusing biometrics with passwords. Passwords can be reset because they are secrets chosen by the user — a new secret can be chosen. Biometrics are inherent physical characteristics. An employee cannot change their face. If a biometric template database is breached and face geometry data is extracted, the affected employees cannot reset their face. This is a fundamental limitation of the inherence factor: compromise is potentially permanent. Mitigation: Windows Hello does not store facial images in a central database — the mathematical template is stored locally in the TPM or secure enclave, making database-level extraction much harder. But the IT director's framing (“reset the biometric like a password”) is factually wrong. Objection 3 — Partially correct: Loss of a FIDO2 key is a real concern and represents a legitimate operational risk. However, “single point of failure” is the wrong framing — this is an availability risk, not a security risk. Mitigations: (1) Register a backup FIDO2 key for each user and store it securely (most organizations issue two keys per employee). (2) Establish an account recovery procedure via a separate verified channel (identity help desk with in-person or video verification). (3) For shared workstations, consider a secondary authentication method as a fallback. The objection identifies a real operational concern but the correct response is a backup key policy, not abandonment of FIDO2. Loss does not compromise security — the key requires a PIN to activate, and the lost key can be de-registered remotely.

Password Security — Exam Tricks