A new token gets generated on each authenticate call. If your application does not have SSO (ie. not calling isValidToken) then it is likely that multiple tokens will get generated.
This bug was introduced in CWD-1040 when randomness was added in to the token. As each token is random, it is never matched to an existing token on an authenticate call.
The fix will involve storing both an identifier_hash and randomized_hash in the Token table such that:
- the indentifier_hash uniquely identifies a user's access (username, directory ID, validation factors such as IP, user-agent, XFF). This can then be used to determine whether we create a new token upon receiving the "authenticate" call. This will still maintain security as the username and password is required to process an "authenticate" call.
- the randomized_hash contains the uniqueness of the identifier_hash and the security of a very large random number. This is used to maintain the session-based SSO cookie and prevents the session fixation attack described in
CWD-1040.
Bug
Medium
Justin Koke
made changes -
David O'Flynn [Atlassian]
made changes -
A new token gets generated on each authenticate call. If your application does not have SSO (ie. not calling isValidToken) then it is likely that multiple tokens will get generated.
This bug was introduced in
CWD-1040when randomness was added in to the token. As each token is random, it is never matched to an existing token on an authenticate call.The fix will involve storing both an identifier_hash and randomized_hash in the Token table such that:
CWD-1040.