Crowd session tokens need to be random and unique to avoid Session Hijacking!!!

related to CWD-216

If a token is ever captured (sniffed, stolen), then all you have to do is use that token when you want to login as that user.

Sure it would require that the user be active with that token, but that is it. Especially since the tokens are predicable!!!! There should be a way in the API to rekey or change the session token to avoid Session Hijacking!!!

The session token is a user's identity for the particular session and hence must be protected. The best way to implement session tokens is to generate and issue a new session token when a user has been successfully authenticated. Any session token used prior to login should be discarded and only the new token should be remembered for the user till the user logs out. This session token should be properly invalidated when the user logs out. When the user logs in again the session token should never be the same value.

Session Token Randomness
It is important that the session Token is unpredictable and the application utilizes a strong method of generating random Token's. It is vital that a cryptographically strong algorithm is used to generate a unique session Token for an authenticated user. Ideally the session Token should be a random value. Do not use linear algorithms based upon predictable variables such as date, time and client IP address.
To this end, the session Token should fulfill the following criteria:
• It must look random - i.e. it should pass statistical tests of randomness.
• It must be unpredictable - i.e. it must be infeasible to predict what the next random value will be, given complete knowledge of the computational algorithm or hardware generating the Token and all previous Token's.
• It cannot be reliably reproduced - i.e. if the Token generator is used twice with exactly the same input criteria, the result will be an unrelated random Token.

Session Token Length
It is important that the session Token be of a sufficient length to make it infeasible that a brute force method could be used to successfully derive a valid Token within a usable timeframe. Given current processor and bandwidth limitations, session token's consisting of over 50 random characters in length are recommended - but make them longer if the opportunity exists.
The actual length of the session token is dependant upon a number of factors:
• Speed of connection - i.e. there is typically a big difference between Internet client, B2B and internal network connections. While an Internet client will typically have less than a 512 kbps connection speed, an internal user may be capable of connecting to the application server at 200 times faster. Thus an internal user could potentially obtain a valid session Token in 1/200th of the time.
• Complexity of the Token - i.e. what values and characters are used within the session Token? Moving from numeric values (0-9) to a case-sensitive alpha-numeric (a-z, A-Z, 0-9) range means that, for the same address space, the session Token becomes much more difficult to predict. For example, the numeric range of 000000-999999 could be covered by 0000-5BH7 using a case-sensitive alpha-numeric character set.