Which Security Mechanism Protects Against Offline Brute-Force Attacks?

350-701 By islever Editorial Last updated

Short answer

C Salting each password with a unique random value before hashing defeats offline brute-force and rainbow-table cracking of a stolen hash database.

Question

Which security mechanism is designed to protect against “offline brute-force” attacks?
  1. Token
  2. MFA
  3. Salt Correct Answer
  4. CAPTCHA

Key Takeaways

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.

Common mistake: 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.

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.

More 350-701 FAQ →

Community Votes

C
100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. Surfside92 👍 1 Answered C
    Brute-force attacks can take place offline or online. In case of an offline attack, the attacker has access to the encrypted material or a password hash and tries different key without the risk of discovery or interference The primary purpose of salt is to defend against dictionary attacks and precomputed rainbow table attacks, which are techniques used to reverse cryptographic hashes and discover the original input
  2. Premium_Pils 👍 1
    MFA and captcha would be methods of online prevention, and salt (altering the hash of a password) for offline prevention. However, salt only makes it more difficult to succeed with the attack, but does not prevent it.
  3. klu16 👍 1 Answered C
    It's Salt.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

← Back to 350-701 Study Guide