Question

I’m currently researching cross-domain SSO implementations, and I may not be able to use a third party SSO provider.

I found a custom implementation online that involves a series redirects and an encrypted querystring parameter.

1. MrUser logs into http://www.foo.com

2. MrUser clicks a link to http://www.bar.com/page.aspx

3. MrUser is not authenticated on bar.com, but bar.com has authentication code that redirects to http://www.foo.com/sso.aspx

4. The sso.aspx page checks for a valid ASP.NET authentication cookie in the cookies collection. If it exists, sso.aspx redirects to http://www.bar.com/page.aspx&ssoauth=[encryptedkey] (where [encryptedkey] is an MrUser’s encrypted id that foo.com and bar.com have agreed on). If there is no valid ASP.NET authentication cookie, then it just redirects without the ssoauth parameter.

5. Bar.com does a check to avoid an infinite redirect loop and then decrypts the ssoauth value. If there is no ssoauth parameter, then MrUser is redirected to the login page, otherwise Bar.com uses the decrypted id to authenticate MrUser before it sends him on to page.aspx.

What are the potential security issues (or other types of issues) with this method?

(cite: http://blogs.neudesic.com/blogs/michael_morozov/archive/2006/03/17/72.aspx)

Edit: In response to the answers citing that the encrypted id is the same every time, and an attacker could use it to gain access – What if bar.com checks the referrer so that it only accepts ssoauth parameters from foo.com?

Answer 1

The first issue is that any encrypt/decrypt scheme can be figured out when it’s plainly visible. You’d be better of implementing something more along the lines of a PKI encryption/decryption platform where the encryption keys are public but the decryption keys are private. The encryption will need to be suitably complex in order to increase the “time to crack”, and that will require resources to perform encrypt/decrypt of the key.

The fact that you have a non-common domain will create the need to supply the encrypted piece in the header (either post or get), and pass it in plaintext. While querystring information is kept secure for the lifetime of the request (edit: assuming SSL), it is not secure from a browser history (making it accessible to common-use computers).

The worst security problem is the concept of “crack one/crack em all”. If one of the servers is compromised and its encryption/decryption algorithms, salt, etc are exposed, it would be possible for an attacker to compromise all systems by generating valid encrypted SSO keys at will and on demand.

None of these problems is terribly tragic. I wouldn’t implement this scheme at a bank or a medical establishment, but for a low risk site like SO or Twitter it would be perfectly acceptable. It will all come down to managing resources, risk, and gain.