-
Bug
-
Resolution: Fixed
-
Highest
-
0.1, (28)
0.2, 0.3, 0.3.1, 0.3.2, 0.3.3, 0.4, 0.4.1, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 1.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.7, 1.1 - OpenID Support, 1.1.1, 1.1.2, 1.2, 1.2.1, 1.2.2, 1.3, 1.3.1, 1.3.2
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.
[CWD-1040] Crowd session tokens need to be random and unique to avoid Session Hijacking!!!
Justin Koke
added a comment - This has now been resolved.
As part of Crowd token generation, we are now creating a very large random number and appending this into the token key that is created.
This randomess removes the ability to simply generate new valid tokens for a client.
However it will not and we will never be able stop session hijacking from occurring (i.e. cookie stealing) without the use of HTTPS, since you need to secure the channel itself to protect from this kind of hijack.
We are happy to discuss this issue further, and possibly open up any new issues that would further improve the security of Crowd, but at present this is the best solution available for Crowd 'out-of-the-box'.
Justin
- Crowd Development
Justin Koke
added a comment - This has now been resolved.
As part of Crowd token generation, we are now creating a very large random number and appending this into the token key that is created.
This randomess removes the ability to simply generate new valid tokens for a client.
However it will not and we will never be able stop session hijacking from occurring (i.e. cookie stealing) without the use of HTTPS, since you need to secure the channel itself to protect from this kind of hijack.
We are happy to discuss this issue further, and possibly open up any new issues that would further improve the security of Crowd, but at present this is the best solution available for Crowd 'out-of-the-box'.
Justin
- Crowd Development
Marko Nordberg
added a comment - The same problem is also with SOAP API application tokens. They are generated in the same way as user session IDs.
Marko Nordberg
added a comment - The same problem is also with SOAP API application tokens. They are generated in the same way as user session IDs. 
J. G. Kelley
added a comment - No crowd's session ID are predictable, you have stated yourself in your answer. One thing you left out is that the same client always has the same session token so the life to crack a session token is as long as the user has an account. I would estimate as little as three days to crack the session token format. But more important since the session token does not change for a client access ever, once the session token is compromised there is no recovery for that user account.
Please review the attached document, if you are still having issues with believing me I am almost finish my program that can be used as a proof and I will post it here as an attachment.
Thanks in advance.
J. G. Kelley
added a comment - No crowd's session ID are predictable, you have stated yourself in your answer. One thing you left out is that the same client always has the same session token so the life to crack a session token is as long as the user has an account. I would estimate as little as three days to crack the session token format. But more important since the session token does not change for a client access ever, once the session token is compromised there is no recovery for that user account.
Please review the attached document, if you are still having issues with believing me I am almost finish my program that can be used as a proof and I will post it here as an attachment.
Thanks in advance. 
David O'Flynn [Atlassian]
added a comment - Hi J.G.,
Tokens in Crowd are authenticated using both IP address of the originating machine, as well as the user's own details. The tokens are also cryptographically secure and not susceptible to being brute-forced.
To hijack a Crowd session token, you'd need to:
- Sniff their token
- Be online at the same time as them
- Be at the same IP address.
Crowd protects against the three weaknesses that lead to session hijacking.
Regards,
Dave.
David O'Flynn [Atlassian]
added a comment - Hi J.G.,
Tokens in Crowd are authenticated using both IP address of the originating machine, as well as the user's own details. The tokens are also cryptographically secure and not susceptible to being brute-forced.
To hijack a Crowd session token, you'd need to:
Sniff their token
Be online at the same time as them
Be at the same IP address.
Crowd protects against the three weaknesses that lead to session hijacking .
Regards,
Dave. 
CWD-893, also resolved in 1.5.1, allows you to set the Secure option on the Crowd token cookie. This will restrict it to https connections, and may be useful for some configurations.