Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-1372

Crowd creates new tokens for applications and users even if valid ones already exist

XMLWordPrintable

      Instead of using the existing tokens Crowd is creating new ones for Applications and Users.

            [CWD-1372] Crowd creates new tokens for applications and users even if valid ones already exist

            shihab added a comment -

            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.

            shihab added a comment - 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 .

              doflynn David O'Flynn [Atlassian]
              rbattaglin Renan Battaglin
              Affected customers:
              7 This affects my team
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: