It is also critical that session ids are not generated using a predictable algorithm such as a counter because if such logic exists, the attacker is no longer guessing but generating session ids. The size has to translate into an impractical effort to guess a valid session id.Using a cryptographically secure random number generator to produce sufficiently long session ids is the best common practice. Another way to prevent an attacker from guessing session ids is to build integrity into the token by adding a hash or signature to the session cookie.A session id guessing attack is a type of brute force attack.Instead of trying to guess the password, the attacker is trying to guess the session id and forge the authentication cookie.It will also protect against developer errors such as using the wrong random number generator function (e.g.the not so random method every system offers alongside the strong method).
However, when it comes to session ids, it is not as simple because sessions expire and do not include an account context.
The attacker generates session ids and tries to make requests using those ids, in hope that they will match actual active sessions.
For example, if a web application session ids are generated in sequence, an attacker can look up their own session id and based on that forge requests using nearby session id values.
We all write bad code no matter how great our process is or how experienced we are. This is why it is so important to layer your security.
A moat is not enough, you also want a wall behind it, and probably some guards behind the wall.