The scenario describes an authentication endpoint that allows a high volume of repeated login attempts with no additional friction, enabling automated scripts to rapidly try large password lists. This is typical of online password guessing and credential stuffing/brute-force style automation. The countermeasure being requested is explicitly one that “forces interaction steps designed to disrupt automation,” which best matches CAPTCHA. CAPTCHA mechanisms introduce a challenge-response test intended to distinguish humans from automated bots, thereby reducing the effectiveness of scripted, high-rate credential attempts.
CAPTCHA is commonly deployed on login and registration pages (and sometimes on password reset flows) to slow down or block automated abuse. When triggered—often after a threshold of failed attempts or suspicious behavior—it forces the requester to complete an interactive step (image selection, puzzle, checkbox with behavioral analysis, etc.). This breaks fully automated attack loops and increases the attacker’s cost, especially when combined with additional controls such as account lockout thresholds, IP reputation, device fingerprinting, and rate limiting.
Why the other options are less aligned to the “disrupt automation” requirement:
Strong hashing algorithms (A) protect stored passwords at rest (e.g., if a database is compromised). They do not directly stop online automated login attempts.
2FA/MFA (B) is excellent for reducing account takeover impact, but it does not inherently prevent high-volume credential submissions; it adds a second factor after correct credentials are provided. Also, the question’s wording strongly points to a bot-disruption interaction step.
Forced periodic password changes (D) is not a primary control for stopping automated login attempts and can introduce usability issues; it does not directly add friction to repeated submissions.
Therefore, the most appropriate countermeasure described is C. Use CAPTCHA challenges on login and registration pages.
