ASD ISM 2065 Ensure secure session cookies with high entropy tokens
What it says
Web application session cookies using opaque bearer tokens that are not digitally signed use non-sequential random identifiers with a minimum of 128 bits of entropy, preferably 256 bits of entropy.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWeb apps should use random session cookie identifiers with high entropy to ensure security.
This control is about making sure that when you log into a website, the little 'login token' it gives you is super hard for hackers to guess or fake. If these tokens aren't secure, someone could pretend to be you online, which might lead to your personal data being stolen or your accounts being misused.
Free. Save your status, tasks and notes.
Why it matters
Low-entropy or predictable opaque session cookie tokens can be guessed, enabling session hijacking and unauthorised access to user accounts and data.
How to implement
IT team should implement secure session tokens: Use a secure software library to generate session tokens with high randomness.
Make sure these tokens have at least 128 bits of unpredictability, which means they are strong enough to resist guessing.
Security officer should educate staff: Run a training session or distribute materials explaining why secure tokens are important and how they protect the business from potential breaches.
Use examples that relate to the team members' roles to reinforce understanding.
Procurement team should assess software vendors: Before purchasing or renewing web application software, check that the vendors guarantee session token security measures in their products.
Review vendor documentation and request information on how they handle session security.
Keep it running
Generate opaque session IDs with a CSPRNG and verify at least 128 bits (preferably 256) of entropy; periodically test for predictability/non-sequential values.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The session token generation documentation: Request internal tech guidelines or vendor documentation that describes how session tokens are generated and managed.
Look at
Whether the documentation specifies high entropy, and not just default settings.
Good evidence
Shows documented assurance of at least 128 bits of entropy.
- Check 2 of 5What an auditor asks for
Look at
Token length and algorithms used to ensure compliance with security standards.
Good evidence
Outcome is settings that align with recommendations from the ACSC.
- Check 3 of 5What an auditor asks for
Ask for
Logs or reports related to token distribution: Request data showing how session tokens are distributed and handled.
Look at
Whether there is consistency and error handling in place.
Good evidence
Includes absence of predictable patterns or recurring errors in token generation.
- Check 4 of 5What an auditor asks for
Ask for
Results from recent security tests or audits that included session token assessment.
Look at
Reports of attempted breaches or weak token detections.
Good evidence
Result shows no successful breaches and recommendations implemented to improve security.
- Check 5 of 5What an auditor asks for
Look at
Attendance lists and training materials.
Good evidence
Outcome includes high staff participation and updated materials that reflect current security standards.
Mappings
Closest match in ISO/IEC 27001: A.8.26, Defining security requirements for applications, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.26.
ISM-2065 requires web applications using opaque bearer session cookies (not digitally signed) to generate non-sequential random session identifiers with at least 128 bits of entropy (preferably 256 bits) to resist guessing/brute force. Annex A 8.26 requires that application security requirements are identified, specified and approved during development or acquisition, which is the point in the SDLC where a concrete requirement like "session identifiers must have ≥128 bits entropy and be generated using a CSPRNG" is documented, approved, and made testable/traceable. In practice, Annex A 8.26 provides the requirements governance mechanism and assurance hook (requirements and acceptance criteria) through which the specific entropy control in ISM-2065 is mandated and verified, but it does not itself prescribe entropy values or session token design details.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.