Access Control and Password Management practice questions

Role-Based Access Control

Why it fails: Role-Based Access Control focuses on assigning permissions based on organizational functions and job duties rather than the authentication method itself. While smart cards can be used within an RBAC system, the requirement for dual-factor authentication describes the authentication mechanism rather than the architectural model for managing user permissions.

Discretionary Access Control

Why it fails: Discretionary Access Control allows the owner of a resource to set access policies based on user identity or group membership. This model is primarily concerned with permission management rather than the underlying authentication process, meaning the use of a smart card and PIN is unrelated to the DAC framework.

Mandatory Access Control

Why it fails: Mandatory Access Control governs access based on system-defined security labels and classifications for subjects and objects. It is a highly restrictive model typically found in government or military environments, but it does not inherently dictate the specific authentication factors used to verify the identity of the subjects involved.

It restricts access to specific IP addresses

Why it fails: The policy logic focuses on the transport security protocol used during the request, not the source IP address. Restricting by IP would require an entirely different condition key, such as aws:SourceIp, which is not present in this JSON structure. Therefore, the policy does not filter traffic based on network location.

It grants public read access to the bucket

Why it fails: The policy contains a Deny effect, which is the most restrictive type of control in this framework. It does not provide any permissions; instead, it prevents access under specific conditions. Public access would require an Allow statement, which is absent from this configuration, meaning it cannot enable any public read capability.

It prevents bucket deletion by unauthorized users

Why it fails: The action specified is s3:GetObject, which only pertains to reading data stored within the bucket. Deletion permissions are controlled by entirely different actions like s3:DeleteBucket or s3:DeleteObject. This policy does not interact with management or administrative actions, making it irrelevant for preventing the deletion of the bucket itself.

Hardware token

Why it fails: A hardware token is a physical device that generates a time-based or event-based code. Because it is a physical object that the user must hold to authenticate, it is categorized as 'something you have.' It is not a biological trait and therefore does not qualify as a biometric factor.

Security question

Why it fails: Security questions rely on the user remembering specific personal information. Since this requires knowledge that the user has learned or created, it is classified as 'something you know.' It does not involve any biological measurement or physical trait, so it is strictly a knowledge-based authentication method, not a biometric one.

Digital certificate

Why it fails: A digital certificate is a data file stored on a computer or smart card that proves a user's identity via cryptography. This is classified as 'something you have' because the user must possess the private key associated with the certificate. It is a digital asset, not a biological human characteristic.

Role-Based Access Control

Why it fails: Role-Based Access Control assigns permissions based on a user's job function or title within the organization. While a user's role might dictate that they belong to a 'shift' group, the act of enforcing access specifically based on the current time is a function of environment attributes, not just the user's role.

Discretionary Access Control

Why it fails: Discretionary Access Control grants owners the ability to define who can access their resources. It does not inherently include logic for time-based restrictions or environmental conditions. In DAC, access is typically granted based on identity or group membership regardless of the time, making it unsuitable for this type of temporal restriction.

Mandatory Access Control

Why it fails: Mandatory Access Control enforces access based on sensitivity labels and security clearances assigned to subjects and objects. These labels are static in nature and do not typically account for environmental factors like time, making MAC a rigid system that is not designed for time-sensitive, dynamic access policy enforcement.

The user is not authenticated

Why it fails: The error message explicitly identifies the user as 'jdoe', confirming that authentication occurred successfully. The problem is not that the user failed to prove who they were, but that they lacked the necessary authorization to perform the requested 's3:PutObject' action on the specified target resource.

The resource path is incorrect

Why it fails: The error log does not indicate that the resource does not exist; it indicates an authorization failure for a specified resource. If the path were incorrect, the system would typically return a 404 or an 'Access Denied' related to listing the directory, not a policy-based rejection for an action.

The system is undergoing maintenance

Why it fails: AccessDenied errors are security-related and indicate a policy conflict, not a system-level issue or maintenance state. If the system were down for maintenance, the error would likely be a 503 Service Unavailable or a connection timeout, rather than an explicit identity and access management policy rejection.

Mandatory Access Control (MAC)

Why it fails: MAC enforces access based on security labels and clearances assigned by a central authority, not on user roles from an LDAP directory. In this scenario, access is determined by the user's finance department role, not by a label-based policy that restricts information flow. MAC is typically used in high-security environments requiring multilevel security, which is not the case here.

Rule-Based Access Control (RuBAC)

Why it fails: RuBAC uses a set of rules, often based on conditions like time of day or IP address, to grant or deny access. While rules can be part of an access control system, the scenario emphasizes role membership from the finance department as the basis for access. RuBAC does not inherently map to organizational roles in a directory service.

Discretionary Access Control (DAC)

Why it fails: DAC allows resource owners to set permissions at their discretion, typically using file ownership and mode bits. In this scenario, access is centrally managed via LDAP and tied to organizational roles, not left to individual users. DAC would not provide the centralized, policy-driven control required by the company's mandate.

/etc/login.defs

Why it fails: login.defs contains default settings for useradd, password aging, and UID/GID ranges. It does not control failed login attempt lockouts. While it can set PASS_MAX_DAYS and similar password expiration policies, it lacks parameters for tracking failed attempts or temporary account disabling. The required lockout behavior after five failures in 10 minutes cannot be configured here.

/etc/securetty

Why it fails: securetty lists terminals from which root is allowed to log in. It is used to restrict root access to specific TTYs and does not handle failed login attempt counting or account lockout. The scenario requires lockout after multiple failures, which is a PAM-based function, not a TTY restriction. Modifying securetty would not implement the desired lockout policy.

/etc/security/pwquality.conf

Why it fails: pwquality.conf controls password complexity requirements such as minimum length, character classes, and dictionary checks. It does not manage account lockout thresholds or lockout durations. The scenario specifically requires failed-attempt lockout behavior, which is handled by pam_faillock or pam_tally2 configuration, not by pwquality. Editing this file would not achieve the desired lockout after five failed attempts.

The user's password has expired.

Why it fails: The scenario explicitly states that the help desk verified the password has not expired. Therefore, this cannot be the cause. Choosing this option ignores the given information. The question asks for the most likely cause given the verified facts, so password expiration is ruled out.

The workstation's clock is out of sync.

Why it fails: A clock skew can cause Kerberos authentication failures, but the scenario does not mention any time-related errors. Typically, clock skew would affect all users on that workstation or domain, not just one user returning from vacation. While possible, it is less likely than an account being disabled, which directly prevents login for that specific user.

The user is typing the wrong password.

Why it fails: If the user were typing the wrong password, the account would likely become locked out after multiple attempts, but the help desk confirmed it is not locked out. Also, the scenario states the password has not expired, but does not confirm the user is entering it correctly. However, the most likely cause given the verified non-lockout and non-expiry is account disablement, not incorrect typing.

Mandating password changes every 30 days

Why it fails: Frequent forced password rotations often lead users to choose weaker, predictable passwords or simply iterate on previous ones. This behavior defeats the purpose of rotation and provides little protection against credential stuffing, as attackers usually test the most recently stolen credentials immediately regardless of how often the password is reset.

Requiring a minimum password length of 8 characters

Why it fails: While length is important for resisting brute-force guessing attacks, it does not stop credential stuffing. Since the attacker already has valid credentials, they do not need to guess the password; they simply need to use it. A short password is just as effective for an attacker as a long one.

Disabling account lockout after failed attempts

Why it fails: Disabling account lockout policies is generally dangerous because it allows attackers to perform unlimited brute-force or dictionary attacks. While it might prevent a DoS situation, it does nothing to stop a credential stuffing attack, which uses valid, known credentials rather than trial-and-error guessing methods that trigger typical lockout mechanisms.

Granting all employees access to the root directory for troubleshooting

Why it fails: Granting root access to all employees is the antithesis of the Principle of Least Privilege. It creates a massive security risk, as any single compromised account could lead to full system destruction or data exfiltration. Troubleshooting should be handled through specific, limited-scope administrative accounts, not by universal access permissions.

Using the same shared password for all administrative accounts

Why it fails: Using shared passwords is a dangerous practice that lacks accountability and violates security best practices. It makes it impossible to audit which individual performed a specific action and ensures that if the shared password is leaked, all administrative accounts are immediately compromised, regardless of how many users have access.

Ensuring all users have administrator rights for software updates

Why it fails: Requiring administrator rights for software updates is unnecessary for standard users and increases security risk. Proper configuration management should allow for automated updates or managed deployment tools that do not require giving end-users full administrative control over their local machines, thereby adhering to the principle of least privilege.

To shorten the length of the stored hash

Why it fails: Adding a salt actually increases the size of the data stored, not decreases it. The goal is to introduce uniqueness and randomness into the hashing process to thwart dictionary attacks, not to optimize for storage space, which is trivial compared to the security benefits provided by salting.

To increase the complexity of the user's password

Why it fails: Salting happens on the server-side during the hashing process and has nothing to do with the password that the user actually chooses. It is a security control applied to the stored hash, not a requirement for the user's password creation process, which should be managed by separate complexity policies.

To facilitate easier password recovery

Why it fails: Salting makes password recovery more difficult if it relies on reverse-engineering the hash, which is exactly the intended security effect. It does not help in providing a 'forgot password' feature, which typically relies on secure email-based reset tokens rather than attempting to recover or decrypt the original user password hash.

Enable NTP synchronization on the authentication server only.

Why it fails: Synchronizing the server's clock with NTP ensures the server has accurate time, but the hardware tokens are offline and cannot receive NTP updates. The tokens' clocks may still drift. While server-side NTP is good practice, it does not compensate for token drift. A time drift window is necessary to accommodate the tokens' independent clocks.

Switch from time-based to event-based OTP tokens.

Why it fails: Event-based tokens use a counter that increments with each button press, eliminating time synchronization dependency. However, switching token types is a major change and may not be feasible if hardware tokens are already deployed. The scenario asks for a solution to the current synchronization problem; a time drift window is a less disruptive and standard fix.

Increase the OTP length to 8 digits.

Why it fails: Increasing the OTP length increases the keyspace and makes brute-force attacks harder, but it does not address time synchronization issues. The problem is that the server and token generate different OTPs because their clocks differ. A longer OTP would still be invalid if the time windows do not match. Length is unrelated to synchronization.

Minimum password age

Why it fails: Minimum password age prevents users from changing their password immediately after a change, which stops them from cycling through passwords to exhaust the history. However, it does not itself prevent reuse; it only enforces a waiting period. Without password history, users could still reuse old passwords after the minimum age passes, so it does not meet the requirement.

Password must meet complexity requirements

Why it fails: Complexity requirements enforce character variety and length, making passwords harder to guess. They do not track or block previously used passwords. A user could reuse the same complex password indefinitely if no history is enforced, so this setting alone does not prevent reuse of the last 24 passwords and is not the correct answer.

Maximum password age

Why it fails: Maximum password age defines how long a password can be used before the user must change it. It does not prevent password reuse; it only forces periodic changes. Setting it to 24 days would require changes every 24 days, but users could alternate between two passwords and still comply, so it fails to prevent reuse of the last 24 passwords.

Credential stuffing

Why it fails: Credential stuffing uses leaked username/password pairs from other breaches to attempt logins. It relies on password reuse and does not involve bypassing a second factor. In this scenario, the attacker already has a valid username and password, but still needs the hardware token. Credential stuffing would not provide the one-time code, so it cannot explain the successful authentication without the token.

Pass-the-hash

Why it fails: Pass-the-hash involves capturing an NTLM hash and using it to authenticate without knowing the plaintext password. It is typically used for lateral movement within Windows environments. However, it does not bypass a hardware token requirement because the token generates a separate one-time code that is not derived from the password hash. The scenario requires both password and token, so pass-the-hash alone would not succeed.

Brute-force attack

Why it fails: A brute-force attack attempts to guess the password or token code by trying many combinations. One-time codes are typically short-lived and rate-limited, making brute-force impractical. Even if the password is guessed, the attacker would still need the current token code, which changes frequently. Brute-force does not explain how the attacker obtained a valid one-time code without the token.

Discretionary Access Control (DAC)

Why it fails: DAC allows resource owners to set permissions at their discretion, which can lead to inconsistent access and over-privilege. It does not inherently enforce least privilege or role-based decisions. In a research lab with sensitive resources, DAC would rely on individual owners to manage access, which is not scalable and does not ensure minimum necessary permissions based on role or resource sensitivity.

Rule-Based Access Control

Why it fails: Rule-based access control uses a set of rules, often based on attributes like time of day or location, to make access decisions. It does not inherently consider user roles or enforce least privilege. While rules can be part of a broader system, they do not directly satisfy the requirements of role-based decisions and minimum necessary permissions as clearly as RBAC and least privilege.

Mandatory Access Control (MAC)

Why it fails: MAC uses security labels and clearances to enforce access, often in military or highly classified environments. While it is strict, it is not specifically based on user roles and may be overly complex for a research lab. The scenario asks for role-based decisions and least privilege, which are better addressed by RBAC and least privilege rather than MAC's label-based approach.

Role-Based Access Control (RBAC)

Why it fails: RBAC assigns permissions to roles rather than individual users, simplifying administration. However, it does not natively support dynamic decisions based on environmental conditions like time of day or resource attributes. While RBAC can be extended with constraints, it lacks the fine-grained, attribute-driven policy evaluation required here. The scenario demands real-time contextual evaluation, which RBAC alone does not provide.

Mandatory Access Control (MAC)

Why it fails: MAC enforces access based on security labels and clearances, typically used in military or high-security environments. It is rigid and centrally controlled, but it does not easily accommodate dynamic environmental attributes like time of day. While MAC provides strong confidentiality, it lacks the flexibility and fine-grained, context-based policy evaluation needed for the trading floor scenario.

Discretionary Access Control (DAC)

Why it fails: DAC allows resource owners to set permissions at their discretion. It is not centralized and does not support dynamic, attribute-based decisions. In a trading floor, DAC would lead to inconsistent policies and potential security gaps. It cannot enforce environmental conditions or provide the centralized auditing and policy management required. Thus, it does not meet the stated requirements.

Rainbow table attack

Why it fails: A rainbow table attack uses precomputed hash tables to crack password hashes. It targets stored password databases, not live login attempts. The scenario involves an attacker attempting to log in with breached credentials, not cracking hashes. Rainbow tables are mitigated by salting hashes, not by second factors. Thus, this attack type does not match the described situation.

Brute force

Why it fails: Brute force attacks systematically try all possible combinations or use large dictionaries against a single account. The scenario describes using breached credentials from other sites, not exhaustive guessing. While brute force can be mitigated by account lockout or second factors, the specific attack vector here is credential stuffing. Brute force would not rely on previously breached username/password pairs.

Password spraying

Why it fails: Password spraying involves trying a few common passwords against many accounts to avoid lockouts. In this scenario, the attacker used a list of breached credentials, which is characteristic of credential stuffing, not spraying. Spraying typically uses a small set of passwords like 'Password123' across many usernames. The presence of a second factor would also mitigate spraying, but the specific attack described is credential stuffing.

CHAP

Why it fails: CHAP (Challenge Handshake Authentication Protocol) uses a three-way handshake and MD5 hashing to avoid sending the password in cleartext. However, it does not encapsulate authentication within a TLS tunnel. CHAP is vulnerable to offline dictionary attacks if the challenge and response are captured. It does not meet the requirement of using TLS for encapsulation, which provides stronger encryption and integrity.

PAP

Why it fails: PAP (Password Authentication Protocol) sends credentials in cleartext. It does not provide encryption or tunneling. Using PAP over the internet would expose passwords to eavesdroppers. While it can be encapsulated within a TLS tunnel (e.g., in a VPN), PAP itself does not provide the necessary security. The requirement is for a protocol that inherently encapsulates authentication within TLS, not one that relies on an external tunnel.

MS-CHAPv2

Why it fails: MS-CHAPv2 is a Microsoft challenge-handshake protocol that uses DES encryption and has known vulnerabilities. It does not encapsulate authentication within a TLS tunnel. While it avoids cleartext passwords, it is susceptible to offline cracking. The requirement specifically calls for TLS encapsulation, which MS-CHAPv2 does not provide. Therefore, it is not suitable for this scenario.

/etc/pam.d/common-password

Why it fails: /etc/pam.d/common-password is a PAM configuration file that controls how password changes are handled, including which pam_unix options are used. While it can influence hashing, the default algorithm is typically set via ENCRYPT_METHOD in /etc/login.defs. On some systems, PAM may override, but the primary system-wide default is in login.defs. Thus, this is not the best answer for setting the default algorithm.

/etc/passwd

Why it fails: /etc/passwd stores user account information but not password hashes; it typically contains a placeholder 'x' in the password field. Editing it does not change the hashing algorithm. It is used for user identification, not authentication configuration. Therefore, it is not the correct file to set the default password hashing algorithm.

/etc/shadow

Why it fails: /etc/shadow stores the actual password hashes and aging information. While it contains the hashes, it is not where the default hashing algorithm is configured. Modifying it directly could break authentication. The algorithm is set in the PAM configuration, not in the shadow file itself. So this is not the correct answer.

PBKDF2

Why it fails: PBKDF2 applies a pseudorandom function (like HMAC-SHA256) many times to derive a key. It allows tuning of iteration count (CPU cost) but does not have a memory cost parameter. This makes it less resistant to GPU attacks compared to memory-hard functions. The requirement for tuning memory costs is not satisfied by PBKDF2, so it is not the optimal choice.

bcrypt

Why it fails: bcrypt is a password hashing function based on the Blowfish cipher. It includes a cost factor that adjusts CPU time, making it resistant to brute-force attacks. However, bcrypt does not allow tuning of memory costs; it is primarily CPU-hard. The scenario requires tuning of both CPU and memory costs, which bcrypt does not provide. Therefore, it is not the best fit.

SHA-256 with a random salt

Why it fails: SHA-256 is a fast cryptographic hash. Adding a salt prevents rainbow table attacks but does not slow down brute-force attempts. GPUs can compute SHA-256 hashes at extremely high rates, making it unsuitable for password storage. The requirement for resistance to GPU-accelerated cracking and tunable CPU/memory costs is not met by SHA-256, even with salting.