Understanding Passwords practice questions

The service uses SHA-256 for password storage

Why it fails: The hashing algorithm determines how fast a password can be cracked offline, not how many online login attempts are allowed. Even with strong hashing, an online brute-force attempt is limited by account lockout thresholds. The lockout mechanism failing is due to architecture, not the strength of the hash.

The system clock is not synchronized

Why it fails: System clock synchronization is vital for log correlation and Kerberos authentication, but it does not influence the logic of an account lockout policy. Lockout mechanisms are based on incrementing counters in the authentication database, which function correctly regardless of the server's time compared to external network time.

The error code 0x4002 indicates a buffer overflow

Why it fails: Error code 0x4002 in this context is defined by the security policy as an account lockout state. It does not signify a memory corruption exploit or buffer overflow vulnerability. The failure to stop the attack is due to the logic of the lockout policy, not an underlying software exploit.

Enforcing a 30-day password rotation schedule

Why it fails: Frequent rotation (e.g., 30 days) is no longer a best practice. It encourages users to create predictable, weak patterns (like 'Summer2023!1', 'Summer2023!2') that are easily guessed. NIST guidelines now suggest changing passwords only when there is evidence of a compromise, rather than on a static, arbitrary timeline.

Mandating a mix of upper, lower, numbers, and symbols

Why it fails: Mandatory character composition requirements actually reduce the entropy of user-selected passwords by constraining the space of choices. Users tend to choose the same characters in the same places (e.g., a symbol at the end). Length is a far more effective security metric than character complexity requirements.

Increase iteration_count to 100,000

Why it fails: Increasing iterations is helpful but does not fix the fundamental issue: MD5 is a weak, fast hash. Even with many iterations, it remains vulnerable compared to algorithms specifically built to be slow and memory-intensive, like Argon2. The algorithm choice is the primary flaw in this configuration.

Set salt_length to 32 bytes

Why it fails: Adding a salt is necessary, but if the underlying algorithm is MD5, the hash remains fast to compute. An attacker can still use a GPU to crack salted MD5 hashes very quickly. A salt is a requirement, but it must be paired with a strong, slow hashing algorithm.

Change auth_method to 'encrypted'

Why it fails: Encryption for stored credentials is not the same as hashing. Encrypted data can be reversed if the key is discovered, whereas hashing is a one-way process. Password storage should always be hashed (using KDFs) to ensure that even if the storage mechanism is breached, the passwords remain protected.

The attacker likely exploited a SQL injection

Why it fails: The strength of the hashing algorithm has no bearing on how the attacker accessed the database. The fact that the hashes were cracked offline only proves they were stolen. Whether they were stolen via SQL injection or another method does not change the evidence that the hashing was cracked.

The salt was too short, facilitating the crack

Why it fails: Bcrypt handles salting internally as part of its algorithm specification. A 'short salt' is not a configuration option in standard bcrypt implementations. The issue here is the strength of the algorithm itself, which was overcome by sheer compute power, not a misconfiguration of the salt length.

The system used an outdated version of bcrypt

Why it fails: Bcrypt does not have 'versions' that are significantly weaker in the way that MD5 or SHA-1 do. Even if an older version of the library were used, the underlying mathematical design of bcrypt remains highly resistant to cracking. The success of the attack is clearly due to compute power.

The account lockout policy is not enforced on the domain controller.

Why it fails: The scenario states that the account is locked after the fifth failed attempt, indicating the lockout policy is enforced. The continued failed logon events are not because the policy is unenforced; they occur because the attacker keeps trying, and the system logs each attempt even though the account is locked.

The failed logon events are generated by the domain controller's own health monitoring service.

Why it fails: Domain controllers do not generate failed logon events for a specific user account due to health monitoring. Such events are typically generated by actual authentication attempts. The pattern of repeated attempts from a single source IP strongly indicates an external attacker, not a built-in monitoring service.

The attacker is attempting to perform a password spray attack against multiple accounts.

Why it fails: A password spray attack typically uses a single password against many accounts, not repeated attempts against one account. The scenario shows repeated attempts against a single user account, which is characteristic of a brute-force attack. Password spraying would generate failed logons for many different accounts, not just one.

Rainbow table attack

Why it fails: A rainbow table attack uses precomputed hash tables to crack password hashes offline. It does not involve online login attempts against an authentication server. The scenario describes online attempts against a single account, so rainbow tables are irrelevant. Rainbow tables also require access to the password hashes, which is not mentioned here.

Credential stuffing

Why it fails: Credential stuffing uses breached username/password pairs from other sites to gain access. It does not involve thousands of attempts per minute on a single account; instead, it tries many different username/password combos. The scenario describes a single account being targeted with many attempts, which is not credential stuffing. Additionally, credential stuffing would likely trigger lockout if many attempts are made on one account, but here the attacker avoids lockout, which is inconsistent.

Brute-force attack

Why it fails: A brute-force attack systematically tries all possible passwords, often causing many failed attempts. In this scenario, the account lockout after 5 failures would normally trigger, but the attacker uses distributed IPs to avoid lockout. However, brute-force typically targets one account with many attempts, which matches the scenario, but the lockout bypass suggests a different technique. Actually, brute-force with IP rotation could still trigger lockout if the lockout is account-based, not IP-based. The scenario states the lockout never triggers, implying the attacker is not exceeding the threshold per account, which contradicts thousands of attempts on one account.

Replace bcrypt with a single round of Argon2id using default parameters, as it is memory-hard and thus faster than bcrypt.

Why it fails: Argon2id is a modern key derivation function that is memory-hard, meaning it requires significant RAM to compute, which actually makes it slower and more resource-intensive than bcrypt in many configurations. Using a single round would defeat its purpose; Argon2id is designed to be tuned with time, memory, and parallelism parameters. Replacing bcrypt with a single-round Argon2id would likely reduce security and may not improve performance, as memory allocation overhead can be substantial.

Switch to SHA-256 with a salt, as it is faster and still considered cryptographically secure for password storage.

Why it fails: SHA-256 is a fast cryptographic hash function, not a key derivation function designed for password storage. Its speed is a disadvantage because attackers can compute billions of hashes per second using GPUs. Salting prevents rainbow tables but does not slow down brute-force attacks. Switching to SHA-256 would drastically reduce the work factor and make the password database far more vulnerable to offline cracking, despite improving authentication speed.

Reduce the bcrypt cost factor to 5 to halve the computation time per authentication attempt.

Why it fails: Reducing the cost factor to 5 exponentially decreases the work required to verify a password, which also makes it exponentially easier for an attacker to crack hashes offline. While it would improve performance, it significantly weakens security. A cost factor of 5 is generally considered too low for modern standards, as it allows an attacker to test many more candidates per second. This trade-off is not acceptable for a financial or sensitive application.

The NT hash was deleted by the attacker to prevent detection.

Why it fails: Attackers typically extract both LM and NT hashes. The absence of the NT hash is unusual and not a standard attacker action. More likely, the system is configured to not store NT hashes? Actually, NT hashes are always stored by default. If the NT hash is missing, it could indicate corruption or tampering, but the scenario focuses on why LM is present. The presence of LM is due to configuration, not attacker deletion of NT.

The password is longer than 14 characters, so only the LM hash is stored.

Why it fails: LM hashing splits passwords into two 7-character halves and converts them to uppercase. Passwords longer than 14 characters cannot be stored as LM hashes because LM only supports up to 14 characters. If the password is longer than 14 characters, the LM hash is typically not stored or is disabled. Therefore, this option is incorrect.

The user's password is less than 15 characters and contains only uppercase letters.

Why it fails: LM hashing converts all characters to uppercase and splits into two 7-character halves. While a password less than 15 characters can be LM hashed, the presence of only uppercase letters is not a requirement; LM hashing uppercases everything anyway. The key factor is the system configuration to store LM hashes, not the password composition. This option is a distractor based on LM's case-insensitivity.

LM hashes use the DES algorithm in ECB mode, which is still considered secure for password storage.

Why it fails: While LM hashes do use DES in ECB mode, DES is outdated and considered insecure due to its short key length (56 bits). ECB mode also has weaknesses, such as identical plaintext blocks producing identical ciphertext blocks. However, the primary flaws of LM are the lack of salting, case conversion, and password splitting, not just the use of DES.

LM hashes are disabled by default on modern Windows systems, but they can be enabled for backward compatibility.

Why it fails: LM hashes are indeed disabled by default on modern Windows systems (since Windows Vista/Server 2008), but the scenario states they are present, indicating they were enabled. This statement is not about the security implications of their presence; it is a factual statement about default settings. The question asks for security implications, so this is not a correct choice.

LM hashes are salted, making them resistant to rainbow table attacks.

Why it fails: LM hashes are not salted. They use a fixed, known algorithm that splits the password into two 7-character halves and hashes each separately. This lack of salting makes them highly susceptible to rainbow table attacks and precomputed hash lookups.

Buffer overflow in the authentication module

Why it fails: Buffer overflows occur due to improper memory handling in compiled code, not hashing algorithms. While a vulnerability, it does not relate to the mathematical weakness of MD5 hashing. The issue with MD5 is the lack of salt and computational speed, not memory corruption or execution control flaws.

SQL injection via the login form

Why it fails: SQL injection is a code-level vulnerability involving improper input sanitization. While it could be used to extract the hash database, the hashing algorithm itself is independent of the vector used to steal the data. Hashing issues relate to password security, not the database query structure.

Man-in-the-middle interception

Why it fails: Man-in-the-middle attacks focus on intercepting data in transit, usually requiring the absence of TLS. Hashing issues are a storage concern rather than a network transport vulnerability. Even if traffic is encrypted, the database remains vulnerable to offline cracking if the underlying hashing algorithm is mathematically weak.

Use a global static pepper appended to all hashes

Why it fails: A global pepper adds security, but it is not a primary best practice compared to unique salting. If the application source code is compromised, the static pepper is often discovered, rendering the protection ineffective. It is an additional layer, but not a replacement for cryptographically sound individual salting.

Truncate passwords to 8 characters to save space

Why it fails: Truncating passwords significantly reduces the entropy and search space for attackers. A shorter password is exponentially faster to crack than a longer one. Best practices dictate allowing long, complex passwords rather than limiting length, as entropy is the best defense against both online and offline guessing.

Store hashes in plain text for performance

Why it fails: Storing hashes in plain text is a critical security failure. If the database is compromised, the attacker has immediate access to every credential without needing to perform any cracking. Hashing must be performed to provide a one-way transformation, and it should never be bypassed for performance reasons.

To increase the length of the password string

Why it fails: While a salt does technically increase the length of the input, this is a byproduct rather than the primary goal. The core function is to add entropy and uniqueness to the hashing process, not to simply satisfy password length requirements or storage constraints in a database table.

To encrypt the password in the database

Why it fails: Salting is part of a one-way hashing process, not encryption. Encryption is reversible with a key, whereas hashing is meant to be irreversible. The salt is stored alongside the hash, but it does not provide the reversible properties required for true data encryption or secure information recovery.

To hide the algorithm type from attackers

Why it fails: Salts do not obfuscate the algorithm used. Attackers can usually infer the algorithm by looking at the hash structure or the application configuration. Security through obscurity regarding the algorithm is not a standard practice; the security should come from the strength of the function and the salt.

Exploiting a buffer overflow to bypass login

Why it fails: Exploiting a buffer overflow is an application-level vulnerability where an attacker corrupts memory. Credential stuffing, by contrast, uses valid credentials. They are distinct types of attacks; one targets the code's integrity, while the other targets the authentication process using legitimate, though stolen, user credentials.

Brute-forcing a password using a dictionary file

Why it fails: Dictionary attacks involve guessing passwords by testing strings from a list against a single account. Credential stuffing differs because it uses known-valid username and password combinations. While both are automated, credential stuffing has a much higher success rate because the passwords are not random guesses.

Intercepting credentials via a phishing email

Why it fails: Phishing is a social engineering technique used to harvest credentials. While the credentials stolen via phishing might be used in a credential stuffing attack, the act of phishing itself is the collection phase, not the stuffing phase where those credentials are tested against other web services.

GPUs have higher clock speeds than CPUs

Why it fails: GPUs generally have lower clock speeds than high-end CPUs. Their performance advantage comes from massive parallelism, not the speed of individual cores. They are optimized for doing many simple tasks at once, which is exactly how hash cracking works, but not because their individual cores are faster.

GPUs access system RAM faster than CPUs

Why it fails: GPUs actually face a bottleneck when accessing system RAM because data must travel across the PCIe bus. They rely on fast, local VRAM for their operations. Their superiority in cracking is due to their internal processing units, not their communication speed with the main system memory.

GPUs use a different instruction set than CPUs

Why it fails: While GPUs and CPUs use different instruction sets, this is not the reason for their performance in cracking. The reason is the number of cores and the specific design for SIMD (Single Instruction, Multiple Data) execution, which maps perfectly to the repetitive nature of brute-forcing password hashes.

Stored in the same database table; prevents rainbow tables

Why it fails: If the pepper is stored in the same database, it provides no protection against an attacker who gains access to that database. The value of a pepper lies entirely in its separation from the hash. If an attacker has both, they can easily reverse the hashing process.

Stored in the application code; ensures performance

Why it fails: Hardcoding a pepper in source code is a major security risk. If the source code is ever pushed to a public repository, the pepper is leaked. It should be managed via secure configuration management or secrets storage, not left inside the application's source code where it is easily discovered.

Stored in the user session; ensures unique hashes

Why it fails: Peppers are global secrets used during the hashing process, not per-session values. Storing a pepper in a user session would mean that the hash changes every time the user logs in, which is impossible for verification. The pepper must be a consistent, secret, server-side configuration value.

KDFs are faster and improve login performance

Why it fails: KDFs are intentionally slower than standard hashes. This slowness is exactly what makes them secure for password storage. If a KDF were faster, it would be less secure, as it would allow attackers to test more password guesses per second during an offline brute-force attack.

KDFs allow for reversible password recovery

Why it fails: KDFs are one-way functions and do not allow for the reversal of a hash to obtain the original password. Password recovery mechanisms should always involve resetting the password, never recovering the existing one, because a system that allows password recovery implies that passwords are stored in a reversible format.

KDFs require less storage space in the database

Why it fails: KDFs typically require more storage space than standard hashes because they need to store parameters like the iteration count, memory cost, and the salt along with the hash output. Storage efficiency is not the goal; security through computational hardness is the primary design requirement for password KDFs.

Increased server CPU usage during off-hours

Why it fails: While unusual CPU usage can indicate malware or unauthorized processing, it is not a direct indicator of a password database compromise. An attacker stealing a database typically performs a quick exfiltration, not a sustained, CPU-intensive process on the victim's production server during off-hours.

A change in the local system time on the server

Why it fails: A change in the system clock is typically a sign of misconfiguration or an NTP issue. It does not provide any diagnostic information about the integrity of the password database or the authentication state of the users within that database, and is unrelated to credential theft.

An increase in valid user password reset requests

Why it fails: While this can be a symptom of frustration, it is not a reliable indicator of a breach. Users often reset passwords because they forget them. A breach is more accurately indicated by unauthorized account access, not the legitimate use of self-service password reset tools by users.

It makes passwords faster to type for users

Why it fails: MFA typically makes the login process slower, not faster. It adds a step for the user, which is a known usability trade-off. The justification for MFA is security, not efficiency; users often view it as an inconvenience, but it is necessary to protect accounts against credential theft.

It eliminates the need for complex passwords

Why it fails: Even with MFA, strong, unique passwords are still necessary. If an attacker gains access to both the password and the MFA token (via session hijacking or social engineering), they can bypass both. MFA is an additional layer of security, not a replacement for strong password hygiene and policy.

It ensures that the password never expires

Why it fails: MFA does not change the rules regarding password expiration. While it reduces the pressure to rotate passwords frequently, the two are independent concepts. An organization can still require password changes even when MFA is implemented, as they serve different purposes in the overall security strategy.

The attacker cannot recover any passwords because the presence of a salt in the hash makes brute-force attacks mathematically infeasible regardless of password strength.

Why it fails: This is false. Salts do not make brute-force attacks infeasible; they only prevent the reuse of precomputed tables and force the attacker to crack each hash individually. Weak passwords remain vulnerable to dictionary and brute-force attacks even with salting. The security of the hash depends primarily on the password's entropy and the computational cost of the KDF, not on the salt alone.

The attacker can decrypt the hashes using the publicly available SHA-512 algorithm because the algorithm is reversible when the salt is known.

Why it fails: This is incorrect. Cryptographic hash functions are one-way by design; they are not encryption algorithms and cannot be decrypted, even when the salt is known. The salt only prevents precomputed rainbow table attacks and ensures identical passwords produce different hashes. Knowing the salt does not provide any shortcut to recovering the original password beyond enabling a fresh cracking attempt.

The attacker can immediately use the hashes to authenticate to other systems via pass-the-hash because SHA-512 crypt hashes are accepted as credentials by SSH and other services.

Why it fails: This is false. Pass-the-hash attacks rely on protocols that accept the hash itself as an authentication token, such as NTLM in Windows environments. SHA-512 crypt hashes in /etc/shadow are not transmitted over the network during SSH authentication; instead, the password is verified locally by the server. An attacker cannot replay these hashes to authenticate to remote systems without first cracking them to plaintext.

MD5

Why it fails: MD5 hashes in shadow files are prefixed with $1$. The $6$ prefix indicates a different algorithm. MD5 is considered weak for password storage due to its speed and vulnerability to collision attacks, and it is not used here.

SHA-256

Why it fails: SHA-256 hashes in shadow files are prefixed with $5$. The $6$ prefix corresponds to SHA-512, not SHA-256. SHA-256 is stronger than MD5 but still not as robust as SHA-512 for password hashing in terms of output length.

bcrypt

Why it fails: bcrypt hashes in shadow files are typically prefixed with $2a$, $2b$, or $2y$. The $6$ prefix is not used for bcrypt. bcrypt is a key derivation function designed to be slow, making it more resistant to brute-force attacks than SHA-512.