Domain 5 · Objective reference 5.6 · Chapter 37 of 62
Implement authentication systems without weakening trust
About 5 minutes · Current ISC2 outline effective 15 April 2024; the announced 15 April 2027 replacement requires separate mapping
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: A secure login includes recovery and session handling.
Explore the anchors
Protect credential binding and verification.
Concept matching activity
Match this task or description to its concept:
Limit token scope duration and exposure.
Choose a concept before checking the explanation.
Access-decision sandbox
Try to edit a fictional record as a reader. Then change one condition and evaluate again. This simplified policy requires authentication, object scope and action permission; real policies have more conditions.
Change the request, then evaluate it.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and mechanisms
- Design, evidence and tradeoffs
Concepts and mechanisms
An authentication implementation includes enrollment, credential storage, verification, session establishment, recovery and revocation. Protocol correctness, protected transport and trustworthy endpoints matter alongside the selected factor. Password verification needs an appropriate password-hashing design rather than reversible storage or fast unsalted hashing. Public-key authenticators depend on correct registration and validation, not simply the existence of a key pair.
Design, evidence and tradeoffs
Test rejected credentials, disabled accounts, recovery abuse, replay conditions and session transitions within authorized scope. Protect secrets in logs and diagnostic tools. Coordinate key or certificate changes so valid users remain supported while obsolete trust is removed. Authentication must fit the application’s authorization and audit design. A successful login test is evidence for only part of the lifecycle.
Worked example
A system strengthens login but leaves a weak recovery route that accepts publicly known information. The overall assurance remains limited by recovery.
Check your understanding
Why is credential recovery part of the authentication threat model?
Show explanation
An attacker who can rebind an authenticator through recovery may bypass the stronger normal sign-in route.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.