SSCP Systems and Application Security Practice Question
A company is deploying a new web application that will be accessible to the public. The security team wants to ensure that session identifiers cannot be predicted or reused by an attacker who captures one over an unencrypted network segment. Which control should be implemented to BEST address this risk?
⚠ Common exam trap
Watch out — candidates often confuse encoding with encryption, or assuming that binding a token to client attributes makes it safe even when it can still be captured in transit.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Generate session identifiers using a cryptographically secure random number generator and transmit them only over TLS.
The risk is twofold: an attacker might predict a session identifier or capture one on the network. Using a cryptographically secure random generator makes prediction infeasible, and requiring TLS for transmission prevents interception. Together they directly mitigate the described threat, whereas encoding, long-lived cookies, and client binding do not address the core weaknesses.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Generate session identifiers using a cryptographically secure random number generator and transmit them only over TLS.
Why this is correct
Cryptographically secure random session identifiers resist prediction, and transmitting them only over TLS prevents interception on the network. Together these address both predictability and capture risks. This is the standard approach for protecting session tokens in public web applications and aligns with secure session management guidance.
- ✗
Encode session identifiers using Base64 to obscure their contents from casual observation.
Why it's wrong here
Base64 is an encoding, not encryption; it is trivially reversible and provides no confidentiality. An attacker who captures the token can decode it instantly. This does not prevent prediction or reuse and creates a false sense of security, so it fails to address the stated risk.
- ✗
Bind session identifiers to the client's IP address and user agent string for validation.
Why it's wrong here
Binding to IP and user agent can add friction for attackers, but both values can be spoofed or change legitimately, causing usability problems and false security. It does not make the identifier unpredictable or prevent capture over an unencrypted segment. This is a supplementary control, not the primary fix for session token exposure.
- ✗
Store session identifiers in persistent cookies with long expiration times to reduce reauthentication.
Why it's wrong here
Long-lived persistent cookies increase the window of exposure if a session identifier is captured. They do not make the identifier unpredictable, and storing it in a persistent cookie makes it more likely to be retained on a shared or compromised device. This worsens the risk rather than mitigating it.
Go deeper
Related to this question
About these practice questions
One of 971 original SSCP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This SSCP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SSCP exam.