Password Security

Password Entropy

Entropy measures the unpredictability (randomness) of a password. Higher entropy means the password is harder to guess or brute-force because there are more possible combinations. Entropy is determined by two factors: the size of the character set used and the length of the password. Increasing either factor increases entropy exponentially.

A password using only lowercase letters (26 characters) at 8 characters length has 26&sup8; = approximately 208 billion combinations. Adding uppercase (52), numbers (62), and special characters (94+) at the same length increases the space to 94&sup8; = approximately 6 quadrillion combinations. Length has a greater marginal impact than character set expansion beyond a certain point — a 16-character password using only lowercase letters has more entropy than an 8-character password using the full character set.

Complexity Requirements

Traditional password complexity policies require passwords to contain characters from multiple categories:

• Uppercase letters (A–Z)
• Lowercase letters (a–z)
• Numbers (0–9)
• Special characters (!@#$%^&* etc.)
• Minimum length of at least 8 characters (modern recommendations push toward 12–16 or longer)

The current NIST SP 800-63B guidance has shifted away from mandatory complexity rules toward longer passwords and passphrases. Complexity rules frequently produce predictable patterns: P@ssw0rd1! satisfies all four categories but is extremely common in credential databases. A random 4-word passphrase (correct horse battery staple) provides significantly more entropy with much higher memorability.

Password Expiration and History

Password expiration policies require users to change their password after a set period: typically every 30, 60, or 90 days. The intent is to limit how long a compromised credential can be used.

Password history prevents users from immediately reusing old passwords. A history setting of 24 means the system stores the hashes of the last 24 passwords, and none of them can be reused. Without password history, users required to change passwords frequently tend to use predictable patterns: Password1 → Password2 → Password3.

Modern security guidance (NIST 800-63B) recommends against mandatory periodic expiration for accounts that have MFA. The reasoning: if a user chooses a strong password and combines it with MFA, forcing quarterly changes produces weaker passwords (users add a number to the end) rather than stronger ones. Expiration is most appropriate where MFA is absent and the risk of undetected credential compromise is high.

Password Managers

A password manager is a software application that generates, stores, and retrieves strong unique passwords for every account. The password database is encrypted with a master password (and typically MFA); only the master password must be remembered by the user. All other passwords can be randomly generated, long, and unique to each service.

Key security properties of password managers:

• Encrypted database: the password vault is encrypted at rest; the master password never leaves the device unencrypted
• Unique passwords per service: if one service is breached, the exposed password is useless at all other services (no credential stuffing opportunity)
• Strong password generation: managers can generate 20+ character random passwords that no human would create or remember
• MFA on the vault: enterprise password managers typically require MFA to open the vault, adding a second layer of protection for the master credential store

Enterprise vs. consumer: Enterprise password managers (1Password Teams, Bitwarden Business, CyberArk) add centralized administration, audit logging, and policy enforcement (minimum password length for stored credentials, automatic rotation). Consumer password managers (1Password, Bitwarden, LastPass) are designed for individual users without centralized management.

Operating systems and browsers also include built-in credential storage (Windows Credential Manager, macOS Keychain, Chrome's saved passwords). These are convenient but typically lack the audit trails and rotation capabilities required for enterprise use.

Passwordless Authentication

Passwordless authentication eliminates the traditional password entirely from the authentication flow. Instead of something-you-know, authentication relies on other factors:

• Biometrics: facial recognition or fingerprint (Windows Hello, Touch ID, Face ID)
• FIDO2/WebAuthn security keys: cryptographic hardware keys
• Magic links: a single-use URL sent to a registered email address
• Push notifications: approve/deny prompts sent to a registered mobile app

Passwordless authentication typically combines with another factor rather than replacing it entirely. Windows Hello uses facial recognition (something you are) validated against a TPM-stored key (something you have). The combination provides strong MFA without a traditional password.

Just-in-Time (JIT) Permissions

Just-in-time permissions grant elevated access only when it is specifically needed and for only as long as it is needed. This implements least privilege at a time-based granularity: rather than a user having permanent admin rights, they have no elevated access by default and request elevation for a specific task.

JIT workflow:

1. User requests elevated access for a specific task (e.g., deploying a server patch)
2. A clearinghouse (privileged access management system) validates the request against policy (approved maintenance window, ticket number, manager approval)
3. The clearinghouse grants temporary admin credentials with a short TTL (time to live), typically 1–4 hours
4. The user performs the task using the temporary credentials
5. The temporary credentials expire automatically when the TTL is reached

Ephemeral credentials: JIT credentials are temporary by design. After expiration, the credentials no longer work even if stolen. An attacker who captures JIT credentials during a maintenance window cannot use them after the window closes. This reduces the value of credential theft against privileged accounts.

Password Vaulting

Password vaulting stores privileged account credentials (root passwords, service account passwords, database administrator credentials) in a secure, access-controlled vault. The primary security goal of vaulting is that the actual credential is never exposed to human administrators. Instead:

• Administrators check out a session via the vault, which proxies the connection to the target system using the vaulted credential
• The credential itself remains in the vault; the admin sees a session, not a password
• All session activity is logged and optionally recorded
• Credentials can be automatically rotated by the vault after each checkout, ensuring the password changes even if it was somehow observed

Password vaulting (implemented by products like CyberArk PAM, BeyondTrust Password Safe, Thycotic Secret Server) addresses the systemic weakness of shared privileged accounts where multiple administrators know a root or administrator password, making accountability impossible and rotation disruptive.

JIT vs. Vaulting: Complementary Controls