Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-11044

Stop encrypting the session id prefix

    Details

    • Support Ticket IDs:

      Description

      Stateful session IDs contain a random 64-bit prefix that is generated from a SecureRandom and then encrypted with a hard-coded key: see com.iplanet.dpro.session.SessionIDConstructorHelper#generateEncryptedID for its current location. That code (when it lived in SessionID) used to have the following comment:

              // TODO note that this encryptedID string is kept only
              // to make this compatible with older Java SDK clients
              // which knew too much about the structure of the session id
              // newer clients will mostly treat session id as opaque
      

      As I'm fairly certain that this backwards compatibility has long since stopped being a concern, AM should stop bothering to do this encryption. This is particularly important when AM is configured to use the AESWrapEncryption method, as this uses at least 10,000 rounds of PBKDF2 to derive the encryption key, which will introduce significant performance issues in this session code.

      Rather than just replacing this code with some raw random bytes, an alternative would be to actually replace this with a MAC tag computed over the rest of the session ID using some new MAC key stored in the session service (HMAC-SHA256 truncated to 128 bits would be fine, or even something like SipHash if you destroy sessions for which the tag verification fails). This would further harden AM's session integrity protection. I would also recommend increasing the StorageKey to 128 bits at the same time.

        Attachments

          Activity

            People

            • Assignee:
              neil.madden Neil Madden
              Reporter:
              neil.madden Neil Madden
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: