A company I'm consulting for has a (quite old) home grown web SSO solution based on an encrypted cookie. The auth flow looks more or less like this:

  • User hits protected page on integrated site
  • Site redirects to central logon site
  • User authenticates and gets sent back to originating site with an encrypted cookie containing username and various other bits regarding their authorizations
  • Integrated site then makes authentication/authorization decisions based on the cookie data

Apps that are integrating with this SSO system are given a "special" decryption library for their platform that knows how to decrypt the SSO cookie. Special in this case simply means they don't make it publicly available, but it's the same library for everyone (per platform).

Out of curiosity, I decided to look into the implementation details of the decryption library. At the core, it's using RijndaelManaged from .NET. However, it has hard coded values for things that seem like they shouldn't be hard coded from my admittedly limited understanding. I'm wondering if they ultimately have an exploitable vulnerability such that knowing the decryption details could hypothetically allow an attacker to craft a valid cookie to impersonate someone else.

The parameters they're using to initialize the RijndaelManaged class are:

The library also includes an RSA public key used to verify an MD5 signature appended to the encrypted cookie.

EDIT: After further thinking, I believe my initial fear about how Rijndael was used is only a problem without the appended signature. While (I think) you can generate modified and valid cipher text using the Rijndael details, you won't be able to create a valid signature without the private key associated with that RSA public key. Is that right?

  • $\begingroup$ Hard coded 128 bit Key means cannot be changed? $\endgroup$ – kelalaka Nov 12 '18 at 20:03
  • $\begingroup$ I believe that's right, at least not without compiling a new decryption library with an updated key. $\endgroup$ – Ryan Bolger Nov 12 '18 at 20:14
  • $\begingroup$ The privacy of the contents of the cookie won't be protected. That's probably not a problem if you're using end to end encryption (TLS). It would be no worse than encoding cookie data as plaintext. (Which usually isn't a problem but depends totally on what the content is and who is meant to see it.) I don't know if the signature part is done correctly but wouldn't be surprised if it wasn't based on the other details here. $\endgroup$ – Future Security Nov 12 '18 at 20:58
  • $\begingroup$ I believe all SSO integrated sites must only run over TLS in this environment. But that's a good point. There's nothing sensitive in the cookie data though. It's the integrity of the data that matters. The ability to generate a fake cookie impersonating someone else and have it accepted at other sites using this same SSO system would be a problem. The signature checking code looks pretty standard from a .NET perspective. $\endgroup$ – Ryan Bolger Nov 13 '18 at 3:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.