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?