Which Security Mechanism Protects Against Offline Brute-Force Attacks?
Which security mechanism is designed to protect against “offline brute-force” attacks?
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests whether you can separate online guessing controls (CAPTCHA, MFA, tokens) from offline hash-cracking defenses (salt), and the trap is reading "brute-force" generically and reaching for MFA.
Offline brute-force attacks happen after an attacker steals a password hash database, so the defense must live inside the stored credential itself. This page confirms that salting (C) is the mechanism designed for that job, while tokens, MFA and CAPTCHA only defend the live authentication path.
Most learners pick MFA or CAPTCHA, reasoning that brute-force means repeated login attempts — but those only work when the attacker must talk to a live service, and an offline cracker never contacts the server.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
A salt is a unique random value generated per password and combined with it before hashing, so the same password produces a different digest on every system and every account. In an offline attack the adversary already holds the hashed credential store, so no lockout, rate limit or challenge can intervene — the only remaining defense is making each guess expensive and non-reusable. Salting defeats precomputed rainbow tables and forces the attacker to spend fresh cracking effort per account instead of cracking one table for millions of hashes at once. Combined with a deliberately slow key-derivation function such as bcrypt, scrypt, Argon2 or PBKDF2, salting is exactly the control OWASP and NIST SP 800-63B recommend for stored secrets. Of the four listed mechanisms, salt is the only one that operates on the credential at rest, which is precisely what an offline attacker possesses.Why the Other Options Are Wrong
Tokens, MFA and CAPTCHA are all enforcement points in a live authentication transaction: they can challenge, delay, or block a remote client that must reach the server. The moment the hash database is exfiltrated, those controls are bypassed entirely — the attacker's cracking rig runs locally, offline, with no CAPTCHA to solve and no second factor to satisfy. CAPTCHA in particular addresses automated online credential stuffing against a login form, not hash cracking. MFA is valuable because a stolen plaintext or cracked password alone is insufficient, but it does not slow down the hash-cracking mathematics at all. Tokens (session or hardware OTP tokens) similarly depend on the legitimate authentication flow being present, which offline cracking removes.Community Comment Notes
Surfside92 frames the scenario well, noting the offline attacker has the encrypted material or hash and "tries different key without the risk of discovery or interference," and that the purpose of salt is "to defend against dictionary attacks and precomputed rainbow table attacks." Premium_Pils adds a fair nuance: salt "only makes it more difficult to succeed with the attack, but does not prevent it" — technically true in isolation, but among these four options only salt is designed for the offline case, and paired with a slow KDF it makes large-scale cracking impractical. klu16 kept it short with "It's Salt," which matches the source key and the unanimous vote for C.Official Reference
Exam Strategy
Ask yourself where the attacker is standing: if they hold the hash file and never touch the server, the answer must be something baked into the credential (salt or a slow KDF); if they are hammering a live login page, think CAPTCHA, lockout, MFA or a token. That one-question filter resolves nearly every brute-force variant on the exam.
Frequently Asked Questions
Why is MFA wrong for an offline brute-force attack?
MFA only challenges an attacker during a live login. Once password hashes are stolen, cracking happens locally with no server contact, so second factors never come into play.
Does salting really stop offline brute-force cracking?
It cannot stop guessing outright, but it kills precomputed rainbow tables and forces unique cracking work per account. Paired with bcrypt, scrypt or Argon2, cracking becomes impractical.