How Do You Limit Breach Impact on a Log-in Database?

Why the Answer Is Correct

The stem names the asset: the log-in database, meaning the store of user IDs and password verifiers. CompTIA's data-protection doctrine is that passwords must never be stored in plaintext or reversibly encrypted; they are stored as salted, one-way hashes so that a stolen copy of the database yields digests that cannot be reversed into working credentials. That is exactly what 'limit potential impact in the event of a breach' means for this asset — the breach still happens, but the extracted data has no authentication value. As dbrowndiver explains, when passwords are hashed the database stores only hash values, so 'even if the database is breached, the attackers cannot easily obtain the original passwords.' Ty13 draws the same line cleanly: tokenization and format-preserving schemes are for card data that must remain retrievable, while 'Hashing is for log-in databases and such where you need to secure the info.' B is therefore the recommendation a security team would actually make, and it aligns with NIST and OWASP guidance on storing memorized-secret verifiers.

Why the Other Options Are Wrong

A (tokenization) is designed for data that must be recovered later, such as PANs in a payment flow; the token is meaningless outside the tokenization vault, but you cannot authenticate a user by comparing a token, and you would still need a verifier for the credential. The commenter a4e15bd argues tokenization keeps the real data 'stored securely elsewhere,' which actually proves the point — the value must be retrievable, exactly what you do not want for passwords. C (obfuscation) is a broad umbrella that includes masking, encryption, and tokenization, but obscurity-based or reversible disguising of log-in data does not survive a breach the way a one-way digest does; a candidate in the thread asks 'Why not C?' and the answer is that obfuscation still leaves recoverable content in many implementations. D (segmentation) is the strongest distractor because SpikeyOG quotes a study guide describing segmentation as isolating components to 'limit the impact of a breach.' That is a real benefit, but segmentation limits lateral movement and blast radius; it does nothing to make the credential records in the compromised log-in database unreadable, and the question asks specifically about that database.

Community Comment Notes

The learner vote overwhelmingly favors hashing (B: 68 vs D: 21), and commenters anchor on the keyword in the stem — one notes that the 'log-in database is the key in the question, which is related to hashing.' drosas84 is blunt that anyone choosing otherwise should 'hit the books,' pointing at the login step as the trigger word. The dissenting minority, led by SpikeyOG, treats the phrase 'limit the impact of a breach' as a segmentation cue lifted from study material, which is the defensible-sounding trap. A smaller faction, including mr.sgtan and a4e15bd, argues for tokenization, but their own reasoning concedes that the original data is preserved securely elsewhere — useful for payment data, wrong for passwords.

Exam Strategy

When a SY0-701 scenario names a specific database or data type, answer for that asset and its protection method, not for the general containment benefit. 'Limit the impact of a breach' is a phrase segmentation questions use for network diagrams; a log-in or credentials database signals hashing. If both appear, choose the control that makes the named data unreadable or unusable after theft.