6a:T520,Password authentication represents the most ubiquitous form of **knowledge-based authentication**—a category where users prove their identity by demonstrating knowledge of a secret. Before examining implementation details, we must understand the theoretical underpinnings that make password authentication meaningful. **The Authentication Problem:** Authentication addresses a fundamental question in security: *How can a system verify that an entity claiming a particular identity actually possesses that identity?* This problem emerges whenever access decisions depend on who is making a request, which is virtually every computing scenario involving multiple users or security boundaries. **The Three Factors of Authentication:** Security theory identifies three categories of authentication factors: 1. **Something you know** — Passwords, PINs, security questions 2. **Something you have** — Physical tokens, smart cards, mobile devices 3. **Something you are** — Biometric characteristics like fingerprints or facial geometry Password authentication falls squarely into the first category. Its dominance stems from several practical advantages: passwords require no special hardware, can be changed instantly if compromised, and are easily understood by users across technical literacy levels.6b:T439,The security of password authentication begins at the moment of user input. Every step from keystroke to verification presents opportunities for attack, and understanding these vulnerabilities is essential for building secure systems. **Input Capture:** When a user types a password, the operating system receives individual keystroke events through the input subsystem. This creates several security considerations: - **Keystroke logging**: Malware at the kernel level can intercept input before it reaches the application - **Shoulder surfing**: Visual observation of keyboard input by nearby observers - **Input echoing**: Displaying characters (even masked as dots or asterisks) provides timing information - **Alternative input methods**: Virtual keyboards, password managers, and paste operations each have distinct threat models Secure systems must protect passwords throughout their brief existence in memory. Passwords should be stored in non-pageable memory (to prevent writing to swap), overwritten immediately after use, and never logged or included in crash dumps.6c:Tb34,#include #include #include #include #include #define MAX_PASSWORD_LEN 128 /** * Secure password capture with memory protection * * Key security measures: * 1. Disable terminal echo to prevent shoulder surfing * 2. Lock memory pages to prevent swap exposure * 3. Explicit memory clearing after use */ int secure_get_password(char *password, size_t max_len) { struct termios old_term, new_term; // Lock the password buffer in memory (prevent swap) if (mlock(password, max_len) != 0) { fprintf(stderr, "Warning: Could not lock password memory "); // Continue anyway - this may fail without privileges } // Get current terminal settings if (tcgetattr(STDIN_FILENO, &old_term) != 0) { return -1; } // Disable echo for password entry new_term = old_term; new_term.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL); if (tcsetattr(STDIN_FILENO, TCSAFLUSH, &new_term) != 0) { return -1; } // Read password printf("Password: "); fflush(stdout); if (fgets(password, max_len, stdin) == NULL) { tcsetattr(STDIN_FILENO, TCSAFLUSH, &old_term); return -1; } printf(" "); // Remove trailing newline size_t len = strlen(password); if (len > 0 && password[len-1] == ' ') { password[len-1] = '\0'; } // Restore terminal settings tcsetattr(STDIN_FILENO, TCSAFLUSH, &old_term); return 0; } /** * Securely clear password from memory * * Uses volatile pointer to prevent compiler optimization * from eliminating the memory clearing operation. */ void secure_clear_password(char *password, size_t len) { volatile char *p = password; // Overwrite with zeros while (len--) { *p++ = 0; } // Unlock memory pages munlock(password, len); } int authenticate_user(const char *username, const char *password); int main() { char password[MAX_PASSWORD_LEN]; char username[64]; printf("Username: "); if (fgets(username, sizeof(username), stdin) == NULL) { return 1; } // Remove newline from username size_t ulen = strlen(username); if (ulen > 0 && username[ulen-1] == ' ') { username[ulen-1] = '\0'; } if (secure_get_password(password, sizeof(password)) != 0) { fprintf(stderr, "Error reading password "); return 1; } // Authenticate (returns 0 on success) int result = authenticate_user(username, password); // CRITICAL: Clear password immediately after use secure_clear_password(password, sizeof(password)); if (result == 0) { printf("Authentication successful "); } else { printf("Authentication failed "); } return result; }6d:T52d,**Transmission Security:** Once captured, the password must travel from the input point to the verification system. This journey presents critical security challenges: **Local Authentication:** For local system login, the password travels through protected kernel memory paths. The login process (typically running as root) reads the password from the terminal driver and passes it to the authentication subsystem. On modern systems, this involves: - **PAM (Pluggable Authentication Modules)**: A modular framework that abstracts authentication logic - **Security contexts**: SELinux or AppArmor policies that restrict access to authentication data - **Process isolation**: Memory protection preventing other processes from reading password buffers **Network Authentication:** Remote authentication introduces network transport vulnerabilities: - **Plaintext transmission**: Sending passwords in clear text (HTTP, Telnet) exposes them to network sniffing - **Encrypted channels**: TLS/SSL wraps the password in encrypted transport - **Challenge-response protocols**: The password itself never traverses the network; only derived values do Modern systems should **never** transmit passwords in plaintext. Even on internal networks, encrypted transport prevents passive eavesdropping and active man-in-the-middle attacks.6e:T505,The verification step determines whether a supplied password matches the expected credential. The design of this mechanism has profound implications for system security. **Naive Verification (Historically Dangerous):** The simplest verification approach stores passwords in plaintext and performs direct comparison: ``` if (strcmp(supplied_password, stored_password) == 0) { grant_access(); } ``` This approach is **catastrophically insecure**. Any breach of the password database exposes every user's credentials immediately. Attackers can use them for credential stuffing attacks against other systems where users have reused passwords. **Cryptographic Hash Verification:** Modern systems never store plaintext passwords. Instead, they store the result of applying a cryptographic hash function: 1. During password creation: `stored_hash = hash(password)` 2. During verification: `computed_hash = hash(supplied_password)` 3. Comparison: `if (stored_hash == computed_hash) { authenticate() }` The critical property of cryptographic hash functions is **one-way computation**: given the hash output, it is computationally infeasible to determine the input. This means that even if an attacker obtains the stored hashes, they cannot directly reverse them to obtain passwords.6f:T401,**Timing Attack Prevention:** A subtle but critical implementation detail is **constant-time comparison**. Naive string comparison (`strcmp`) returns early when mismatched characters are found: - Password `abc123` vs. `xyz789`: Fails immediately (first character mismatch) - Password `abc123` vs. `abc456`: Fails later (fourth character mismatch) This timing difference, though measured in nanoseconds, is exploitable. Attackers can statistically analyze response times to deduce correct password prefixes character by character. Secure implementations use constant-time comparison that examines every byte regardless of mismatches: ```c int secure_compare(const unsigned char *a, const unsigned char *b, size_t len) { unsigned char result = 0; for (size_t i = 0; i < len; i++) { result |= a[i] ^ b[i]; // Accumulate differences without early exit } return result; // 0 if equal, non-zero if different } ``` This function always examines all bytes, preventing timing-based information leakage.70:T545,Understanding how passwords are attacked is essential for building effective defenses. Attackers employ multiple strategies, each with distinct characteristics and countermeasures. **1. Brute Force Attacks:** The most straightforward approach: systematically try every possible password. For an 8-character alphanumeric password (62⁸ ≈ 218 trillion possibilities), this seems impractical—but modern hardware changes the calculation: - **CPU attack**: ~10⁶ attempts/second → ~7,000 years - **Single GPU**: ~10⁹ attempts/second → ~7 years - **GPU cluster (100 GPUs)**: ~10¹¹ attempts/second → ~25 days - **Specialized ASICs**: ~10¹² attempts/second → ~2.5 days Brute force is a baseline attack; smarter approaches reduce the search space dramatically. **2. Dictionary Attacks:** Dictionary attacks leverage the predictability of human password choices. Instead of trying all possible strings, attackers try: - Common passwords (123456, password, qwerty) - Dictionary words in various languages - Common names, places, and dates - Previously leaked passwords from breaches The RockYou breach (2009) leaked 32 million plaintext passwords, revealing that: - The most common password ('123456') was used by 290,000 accounts - The top 5,000 passwords covered 20% of all accounts - ~40% of passwords were pure lowercase letters71:T64f,**3. Rainbow Table Attacks:** Rainbow tables represent a sophisticated time-memory trade-off. Instead of computing hashes during an attack, attackers precompute hash values for millions of potential passwords and store the mappings: ``` hash(password) → password hash(123456) = e10adc3949ba59abbe56e057f20f883e → 123456 hash(password) = 5f4dcc3b5aa765d61d8327deb882cf99 → password ... ``` When attackers obtain a password hash, they simply look it up in the table. A comprehensive rainbow table for 8-character alphanumeric passwords using MD5 requires approximately: - ~460 billion entries - ~5TB storage (with chain compression) - Near-instant lookups after table construction **Defense: Salting** Salting defeats rainbow tables by prepending a unique random value (salt) to each password before hashing: ``` stored_hash = hash(salt + password) ``` With a 128-bit salt, attackers would need to precompute a separate rainbow table for each possible salt—a computationally impossible task. Every password effectively exists in its own hash space. **4. Pass-the-Hash Attacks:** In certain authentication protocols (notably NTLM), the password hash itself serves as the credential. Attackers who obtain stored hashes can authenticate *without knowing the actual password*: 1. Attacker compromises a system and extracts password hashes from memory or registry 2. Attacker uses the hash directly to authenticate to other systems 3. No password cracking required—the hash is the password This attack vector highlights that protecting stored hashes is as critical as protecting passwords themselves.72:T4d6,Each major operating system implements password authentication through distinct architectural patterns. Understanding these implementations reveals how security principles manifest in production systems. **Linux/Unix Authentication:** Modern Linux systems use a layered authentication architecture: 1. **Login Process**: The `/bin/login` program or display manager captures credentials 2. **PAM (Pluggable Authentication Modules)**: A flexible framework that abstracts authentication logic 3. **Shadow Password File**: `/etc/shadow` stores password hashes, readable only by root 4. **NSS (Name Service Switch)**: Resolves user information from various sources (files, LDAP, etc.) The PAM architecture deserves particular attention. PAM allows system administrators to configure authentication policies without modifying applications. A PAM configuration for login might include: ``` auth required pam_unix.so # Check password against /etc/shadow auth requisite pam_deny.so # If pam_unix fails, deny immediately account required pam_unix.so # Check account validity session required pam_unix.so # Session setup password required pam_unix.so sha512 # Password changes use SHA-512 ```73:T716,/** * Simplified PAM authentication flow * * This illustrates how applications interact with PAM * for password authentication. */ #include #include #include int authenticate_via_pam(const char *username, const char *password) { pam_handle_t *pamh = NULL; int retval; // Custom conversation function to provide password struct pam_conv conv = { misc_conv, // Standard conversation function NULL }; // Initialize PAM transaction // "login" refers to the service configuration in /etc/pam.d/ retval = pam_start("login", username, &conv, &pamh); if (retval != PAM_SUCCESS) { fprintf(stderr, "pam_start failed: %s ", pam_strerror(pamh, retval)); return -1; } // Authenticate the user // PAM will check the password against configured backends retval = pam_authenticate(pamh, 0); if (retval != PAM_SUCCESS) { fprintf(stderr, "Authentication failed: %s ", pam_strerror(pamh, retval)); pam_end(pamh, retval); return -1; } // Check account validity (expiration, access restrictions) retval = pam_acct_mgmt(pamh, 0); if (retval != PAM_SUCCESS) { fprintf(stderr, "Account invalid: %s ", pam_strerror(pamh, retval)); pam_end(pamh, retval); return -1; } // Clean up PAM handle pam_end(pamh, PAM_SUCCESS); printf("User %s authenticated successfully ", username); return 0; } /** * /etc/shadow file format: * username:$algorithm$salt$hash:lastchange:min:max:warn:inactive:expire: * * Example: * john:$6$xyz...$abc...def:18900:0:99999:7::: * * $6$ = SHA-512 * $5$ = SHA-256 * $1$ = MD5 (deprecated) */74:T5ab,**Windows Authentication:** Windows employs a more complex authentication architecture: 1. **Winlogon**: The secure desktop process that handles login UI (runs in Session 0) 2. **Credential Providers**: Pluggable modules that capture user credentials 3. **LSASS (Local Security Authority Subsystem)**: Core authentication service 4. **SAM (Security Account Manager)**: Local account database (or Active Directory for domain accounts) 5. **NTLM/Kerberos**: Authentication protocols for local and domain authentication Windows stores password hashes in the SAM database (located in `C:\Windows\System32\config\SAM`, encrypted with the system key). The hash format has evolved: - **LM Hash** (Legacy): Extremely weak, case-insensitive, limited to 14 characters. Disabled by default since Vista. - **NT Hash**: MD4-based, no salt. Better than LM but still vulnerable to rainbow tables. - **NTLMv2**: Improved challenge-response protocol with per-session challenges. **macOS Authentication:** macOS implements authentication through: 1. **loginwindow**: The login UI process 2. **DirectoryService/OpenDirectory**: User account management framework 3. **Secure Enclave**: Apple Silicon's hardware-protected key storage 4. **System Keychain**: Encrypted storage for credentials and secrets On Apple Silicon devices, password verification occurs within the Secure Enclave, providing hardware-based protection against software-based extraction attacks.75:Tcaa,""" K-Anonymity based password breach checking. This approach checks if a password appears in breach databases without revealing the actual password to the checking service. """ import hashlib import requests from typing import Tuple def check_password_breach(password: str) -> Tuple[bool, int]: """ Check if a password has been exposed in a data breach. Uses the Have I Been Pwned k-Anonymity API: https://haveibeenpwned.com/API/v3#PwnedPasswords Returns: (is_pwned, count): Whether password is breached and how many times seen """ # Step 1: Hash the password with SHA-1 sha1_hash = hashlib.sha1( password.encode('utf-8') ).hexdigest().upper() # Step 2: Split hash into prefix (5 chars) and suffix prefix = sha1_hash[:5] suffix = sha1_hash[5:] # Step 3: Query the API with only the prefix url = f"https://api.pwnedpasswords.com/range/{prefix}" response = requests.get(url, timeout=10) if response.status_code != 200: raise Exception(f"API request failed: {response.status_code}") # Step 4: Check if our suffix appears in the response # Response format: SUFFIX:COUNT\r for line in response.text.splitlines(): hash_suffix, count = line.split(':') if hash_suffix == suffix: return True, int(count) return False, 0 def validate_password(password: str) -> list[str]: """ Comprehensive password validation including breach check. Returns list of issues (empty list = password is acceptable). """ issues = [] # Minimum length check (NIST recommends at least 8) if len(password) < 8: issues.append("Password must be at least 8 characters") # Maximum length (allow long passphrases) if len(password) > 64: issues.append("Password exceeds maximum length of 64 characters") # Check for common patterns that indicate weak passwords common_patterns = [ 'password', '12345678', 'qwerty', 'letmein', '111111', 'abc123', 'admin', 'welcome' ] lower_password = password.lower() for pattern in common_patterns: if pattern in lower_password: issues.append(f"Password contains common pattern: {pattern}") # Breach database check try: is_pwned, count = check_password_breach(password) if is_pwned: issues.append( f"Password found in data breaches ({count:,} times). " "Choose a different password." ) except Exception as e: # Log but don't block if service unavailable print(f"Warning: Breach check failed: {e}") return issues # Example usage if __name__ == "__main__": test_passwords = [ "password123", # Common, definitely breached "correct horse battery staple", # Famous passphrase "Xk9#mP2$vL7@nQ4", # Random-looking but may still be breached ] for pwd in test_passwords: issues = validate_password(pwd) if issues: print(f"'{pwd}': REJECTED") for issue in issues: print(f" - {issue}") else: print(f"'{pwd}': ACCEPTED")63:{"json":{"id":"seed_0732e10086c0cd7ea9f651cf220dabfe","slug":"os-authentication","category":"Operating Systems","topic":"Authentication","title":"Authentication","description":"Master the fundamental concepts of authentication in operating systems. Explore password-based authentication, multi-factor authentication, biometric systems, authentication protocols, and secure password storage mechanisms that protect modern computing systems.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_604d70f9d3b3f2a37b5dff78c6d2aa3e","title":"Password Authentication","order":0,"content":[{"id":"opening-hook","title":"The Gateway to System Security","content":[{"data":{"content":"Every day, billions of authentication events occur across the digital landscape—users proving their identity to access banks, email, corporate systems, and personal devices. At the heart of this vast authentication ecosystem lies a deceptively simple concept: the **password**.\n\nDespite decades of innovation in security technology, passwords remain the dominant authentication mechanism across virtually all computing platforms. Understanding password authentication isn't merely academic—it's essential knowledge for any systems engineer who builds, maintains, or secures software that people depend upon.\n\nThis page provides an authoritative, deeply technical exploration of password authentication from the operating system's perspective. We'll examine how passwords are captured, transmitted, verified, and protected against an ever-evolving landscape of attacks."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete lifecycle of password authentication—from user input to system verification. You'll grasp the mathematical foundations of password security, recognize common vulnerabilities, and appreciate the architectural decisions that make modern password systems resilient against sophisticated attacks.","variant":"info"},"type":"callout"}]},{"id":"fundamentals-password-auth","title":"Fundamentals of Password Authentication","content":[{"data":{"content":"$6a"},"type":"text"},{"data":{"rows":[["**Knowledge (Something you know)**","Passwords, PINs, security questions","No hardware required, easily changeable, universally understood","Can be forgotten, shared, or stolen through social engineering"],["**Possession (Something you have)**","Smart cards, hardware tokens, phones","Physical theft required for compromise, supports cryptographic operations","Can be lost, stolen, or damaged; requires distribution infrastructure"],["**Inherence (Something you are)**","Fingerprints, facial recognition, iris scans","Always available, difficult to share or transfer","Cannot be changed if compromised, privacy concerns, false accept/reject rates"]],"caption":"Authentication Factor Comparison","headers":["Factor Type","Examples","Strengths","Weaknesses"]},"type":"table"},{"data":{"content":"**The Password Verification Model:**\n\nAt its core, password authentication follows a challenge-response model:\n\n1. **Identity Claim**: The user asserts an identity (typically a username)\n2. **Challenge**: The system requests proof of that identity (the password prompt)\n3. **Response**: The user provides the secret (entering the password)\n4. **Verification**: The system validates the response against stored credentials\n5. **Decision**: Access is granted or denied based on verification outcome\n\nThis simple model conceals substantial complexity in each step. How the password is captured, transmitted, and verified—and how the reference credential is stored—determines the security properties of the entire system."},"type":"text"},{"data":{"icon":"Info","title":"Historical Context","content":"Password authentication emerged in the early 1960s with MIT's Compatible Time-Sharing System (CTSS). Fernando Corbató introduced passwords to partition user files on shared computing resources. The fundamental concept has remained remarkably stable for over six decades, though implementation security has evolved dramatically.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"password-capture-transmission","title":"Password Capture and Transmission","content":[{"data":{"content":"$6b"},"type":"text"},{"data":{"fileName":"secure_password_handling.c","languages":[{"code":"$6c","label":"C","value":"c"}]},"type":"code"},{"data":{"content":"$6d"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Memory Exposure Risk","content":"Passwords in memory are vulnerable to cold boot attacks, memory dump exploits, and hardware-based side channels. Production systems should use memory-safe password handling libraries that minimize exposure time and employ secure erasure patterns.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"password-verification","title":"Password Verification Mechanisms","content":[{"data":{"content":"$6e"},"type":"text"},{"data":{"left":[{"data":{"items":["Plaintext password storage","Simple comparison operations","No computational cost to verify","Database breach = full compromise","Identical passwords have identical storage","Vulnerable to rainbow table attacks"],"title":{"icon":"XCircle","text":"Insecure Verification","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Salted, iterated hash storage","Constant-time comparison","High computational cost per attempt","Database breach requires brute force","Each password has unique storage","Rainbow tables infeasible"],"title":{"icon":"CheckCircle","text":"Secure Verification","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"$6f"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Defense in Depth","content":"Modern password verification combines multiple protective mechanisms: cryptographic hashing, per-password salts, computationally expensive key derivation functions, constant-time comparison, and rate limiting. Each layer addresses different attack vectors, and together they create a robust defense.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"password-entropy-strength","title":"Password Entropy and Strength","content":[{"data":{"content":"The security of password authentication ultimately depends on the **entropy**—the measure of unpredictability—in user-chosen passwords. Understanding entropy provides the mathematical foundation for password policy decisions.\n\n**Information-Theoretic Entropy:**\n\nIn information theory, entropy measures the amount of uncertainty in a random variable. For passwords, entropy quantifies how difficult it is to guess the password through exhaustive search.\n\nFor a password of length *L* selected from an alphabet of *N* possible characters, the maximum entropy is:\n\n***H = L × log₂(N) bits***\n\nThis assumes each character is selected independently and uniformly at random—an assumption that dramatically overestimates the entropy of human-chosen passwords."},"type":"text"},{"data":{"rows":[["Digits only (0-9)","10","3.32 bits","26.6 bits"],["Lowercase letters (a-z)","26","4.70 bits","37.6 bits"],["Mixed case (a-z, A-Z)","52","5.70 bits","45.6 bits"],["Alphanumeric (a-z, A-Z, 0-9)","62","5.95 bits","47.6 bits"],["Full ASCII printable","95","6.57 bits","52.6 bits"],["4-word passphrase (7776-word list)","7776⁴","~51.7 bits total","51.7 bits"]],"caption":"Entropy of Different Password Compositions","headers":["Character Set","Characters (N)","Entropy per Character","8-char Password Entropy"]},"type":"table"},{"data":{"content":"**Human Password Behavior:**\n\nThe theoretical entropy calculations above assume truly random selection. In practice, human-chosen passwords exhibit predictable patterns that dramatically reduce effective entropy:\n\n- **Dictionary words**: Users favor real words over random character sequences\n- **Predictable substitutions**: 'password' becomes 'p@ssw0rd', providing minimal additional security\n- **Structural patterns**: Capital letter first, numbers at end (e.g., 'Monkey123!')\n- **Personal information**: Names, dates, locations that attackers can research\n- **Password reuse**: The same password across multiple services\n\nResearch by Florencio and Herley (Microsoft Research) found that the average user's password has approximately **40 bits of effective entropy**—far below the theoretical maximum.\n\n**Practical Attack Feasibility:**\n\nTo understand password strength requirements, we must consider attacker capabilities:"},"type":"text"},{"data":{"rows":[["Online attack (rate limited)","10","~3,500 years","~3.8 × 10¹⁶ years"],["Offline attack (single GPU)","10⁹","~1 second","~38,000 years"],["Offline attack (GPU cluster)","10¹²","~1 millisecond","~38 years"],["Nation-state resources","10¹⁵","~1 microsecond","~2 weeks"]],"headers":["Attack Scenario","Attempts per Second","Time to Crack 40-bit Password","Time to Crack 80-bit Password"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Offline Attack Threshold","content":"If password hashes leak, attackers can perform offline attacks at rates limited only by hardware. A 40-bit password, secure against online attacks, falls in seconds to modern GPU-based attacks. This is why proper password storage (covered later in this module) is critical—it increases the computational cost per attempt by orders of magnitude.","variant":"warning"},"type":"callout"},{"data":{"content":"**Passphrases vs. Complex Passwords:**\n\nThe XKCD 'correct horse battery staple' insight—that a passphrase of four random common words can have more entropy than a shorter complex password—has influenced modern password guidance.\n\n**Complex password** (e.g., `Tr0ub4dor&3`): ~28-30 bits of entropy (pattern predictability)\n**Random passphrase** (e.g., `correct horse battery staple`): ~44 bits (assuming 2048-word list)\n\nThe passphrase is:\n- Higher entropy (more guessing resistance)\n- More memorable (reduces password reuse and sticky notes)\n- Faster to type (muscle memory for words)\n\nNIST Special Publication 800-63B now recommends allowing long passphrases and discouraging complexity rules that produce predictable patterns."},"type":"text"}],"titleType":"number","titleNumber":4},{"id":"password-attack-vectors","title":"Common Password Attack Vectors","content":[{"data":{"content":"$70"},"type":"text"},{"data":{"items":["**Credential Stuffing** — Using leaked username/password pairs from one breach to attack other services, exploiting password reuse across sites","**Rainbow Table Attacks** — Precomputed hash-to-password lookup tables that trade storage for attack speed; defeated by salting","**Phishing** — Social engineering attacks that trick users into entering passwords on counterfeit sites","**Keylogging** — Malware that captures keystrokes at the OS or driver level before passwords reach applications","**Shoulder Surfing** — Physical observation of password entry, increasingly relevant in shared workspaces","**Man-in-the-Middle** — Intercepting authentication traffic between client and server, typically when encryption is absent or compromised"],"title":{"icon":"AlertCircle","text":"Major Password Attack Categories","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"$71"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Credential Stuffing at Scale","content":"Following major breaches, attackers perform credential stuffing attacks using billions of leaked credentials. The 2019 'Collection #1' dump contained 773 million unique email addresses and 21 million unique passwords. If you've reused a password on a breached service, that password is likely in attacker databases.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"os-login-architectures","title":"Operating System Login Architectures","content":[{"data":{"content":"$72"},"type":"text"},{"data":{"fileName":"pam_authentication_flow.c","languages":[{"code":"$73","label":"C","value":"c"}]},"type":"code"},{"data":{"content":"$74"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Cross-Platform Commonality","content":"Despite architectural differences, all major operating systems share core principles: separation of credential capture from verification, protected storage of password hashes, privilege separation for authentication services, and pluggable authentication frameworks that support extensibility.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"password-policy-design","title":"Password Policy Design","content":[{"data":{"content":"Password policies attempt to enforce password security through rules and constraints. However, decades of research have revealed that many traditional policies are counterproductive. Modern guidance emphasizes usability alongside security.\n\n**Traditional Policies (Often Counterproductive):**"},"type":"text"},{"data":{"rows":[["Complexity requirements","Increase search space","Users create predictable patterns (Password1!)"],["Forced periodic changes","Limit exposure window","Users increment numbers (Password1, Password2)"],["No previous password reuse","Prevent reuse of compromised passwords","Users make minimal changes"],["Maximum length limits","Implementation convenience","Discourages passphrases"],["Character type mandates","Ensure diversity","Creates predictable patterns"]],"headers":["Policy","Intent","Actual Effect"]},"type":"table"},{"data":{"content":"**Modern Password Policy Guidance (NIST 800-63B):**\n\nThe 2017 NIST Digital Identity Guidelines dramatically revised password recommendations:"},"type":"text"},{"data":{"type":"ordered","items":["**Allow long passphrases** — Support at least 64 characters. Don't truncate passwords.","**Remove composition rules** — Don't mandate uppercase, lowercase, numbers, and symbols. These create predictable patterns.","**Stop periodic rotation** — Only force password changes when compromise is suspected.","**Check against breach lists** — Reject passwords found in known breach databases.","**Allow all characters** — Accept spaces, unicode, emoji. Don't restrict the character space.","**Show password option** — Allow users to see what they're typing to reduce errors.","**Support password managers** — Don't block paste into password fields.","**Rate limit authentication** — Implement throttling and lockouts against brute force."],"title":{"icon":"CheckCircle","text":"NIST SP 800-63B Password Recommendations","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Breach Password Check Implementation:**\n\nChecking passwords against breach databases requires care to avoid exposing passwords to the checking service. The **k-Anonymity** model provides a privacy-preserving approach:\n\n1. Client computes SHA-1 hash of password: `5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8`\n2. Client sends only first 5 characters to server: `5BAA6`\n3. Server returns all hashes matching that prefix (~500 potential matches)\n4. Client checks if full hash appears in returned list locally\n\nThis reveals only a 5-character prefix (insufficient to identify the password) while still allowing breach detection. The Have I Been Pwned service implements this model with over 600 million compromised passwords."},"type":"text"},{"data":{"fileName":"breach_check.py","languages":[{"code":"$75","label":"Python","value":"python"}]},"type":"code"},{"data":{"icon":"Info","title":"The Usability-Security Balance","content":"Password policies that frustrate users produce worse security outcomes. Users required to create complex passwords and change them frequently will write them down, use predictable patterns, or reuse them across services. Modern policies prioritize length over complexity and only mandate changes when compromise is suspected.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-key-takeaways","title":"Summary and Key Takeaways","content":[{"data":{"content":"Password authentication—despite its age and limitations—remains the dominant form of user authentication across virtually all computing platforms. This page has explored the complete landscape of password authentication from the operating system perspective."},"type":"text"},{"data":{"type":"ordered","items":["**Password authentication is knowledge-based** — Users prove identity by demonstrating knowledge of a secret, distinct from possession-based (tokens) or inherence-based (biometrics) factors.","**Secure password handling requires defense in depth** — From input capture to verification, every step presents attack opportunities that require specific countermeasures.","**Entropy determines password strength** — The unpredictability of a password, measured in bits, determines its resistance to guessing attacks. Human-chosen passwords have far less entropy than theoretical maximums.","**Multiple attack vectors target passwords** — Brute force, dictionary attacks, credential stuffing, rainbow tables, and social engineering all threaten password security.","**Operating systems implement password authentication through layered architectures** — PAM on Linux, LSASS on Windows, and DirectoryService on macOS all provide modular, extensible authentication frameworks.","**Modern password policies prioritize usability** — NIST guidance now recommends long passphrases, removing complexity mandates, eliminating periodic rotation, and checking against breach databases."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Looking Ahead:**\n\nWhile passwords remain dominant, their limitations have driven the development of complementary and alternative authentication mechanisms. The next page explores **Multi-Factor Authentication (MFA)**—combining passwords with additional factors to create authentication systems that are more resilient than any single factor alone."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a comprehensive understanding of password authentication—its theoretical foundations, implementation patterns, attack vectors, and policy considerations. This knowledge forms the foundation for understanding more advanced authentication mechanisms.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_cb7f3e37c5b446aab5e0f024cf277017","title":"Multi-Factor Authentication","order":1,"content":null,"isLocked":true},{"id":"seed_332ab3b9700a09d422357f8846393731","title":"Biometrics","order":2,"content":null,"isLocked":true},{"id":"seed_aacdf017a55abc0367fe415ccab59c62","title":"Authentication Protocols","order":3,"content":null,"isLocked":true},{"id":"seed_aac303edb518adcdb9b807b9b97b29da","title":"Password Storage","order":4,"content":null,"isLocked":true}]}}