What are the potential security issues in this implementation of SSO?

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.

Answer 2

Anyone can use encryptedKey to gain access as MrUser. Rather than encryption, a signing or message authentication service is needed. The authenticated message should include a nonce with the user identifier to prevent replays.

Protocols like this are hard to devise. Even TLS, which was widely used and reviewed for years has security flaws. Don't try to use an unproven authentication mechanism.

Answer 3

A potential problem is if ssoauth encrypted key is only the User's encrypted ID. Such a setup will result in providing the same key each time, which can therefore be both reused, by original user or worse by a third party.

One way to avoid this situation is to keep the time-of-day clocks of foo.com and bar.com servers relatively synchronized and to issue keys which include the date/time (modulo 5 minutes).

People are often tempted to use the web client's IP address as one of the elements of this encryption, but this is a bad idea, for several proxies and gateways use different public IPs within their pools to access different domains/servers.

Another way to allow for a distinct password each time is to have bar.com's redirect to

http://www.foo.com/sso.aspx

include a parameter such as

http://www.foo.com/sso.aspx?ParamForKey=some_random_number

and to use ParamForKey as part of the encryption process

Answer 4

There are several issues: 1) How long is the encrypted token valid? It should be valid only for a couple of seconds. Easy if all servers are on ntp. Having expiry also protects user in case they have the link containing encrypted token is left around. Validating nonce is difficult if you have many bar.com servers - you could say that having an expiry of a couple of seconds should mitigate replay.

2) Problem with SSO cross domain is single sign off. What if users sign off foo.com. The session on bar.com must be invalidated. You could XSRF bar.com logout as a hack :). You should have bar.com beacon foo.com every 15 minutes to see if user is still logged in.

3) What if user does not sign off bar.com and it is a multi-user computer and another user signs onto foo.com? You have to ensure that you if userids do not match previous user's data is not shown.

4) As someone else mentioned, you probably want a signature or HMAC on userid rather than encryption. If you do encrypt, remember to protect the integrity of the ciphertext. You do not want user A flipping bits in ciphertext to see if they can access User B's data on bar.com.

I would have the redirect over https.

Finally, as everyone said, referrers can be spoofed. Don't trust them.