[thelist] Single Sign On Security

Judah McAuley judah at wiredotter.com
Tue Mar 2 23:28:56 CST 2010


On Tue, Mar 2, 2010 at 4:48 PM, Bill Moseley <moseley at hank.org> wrote:
> Problems I see are for the account creation process (well, any third-party
> request):
>
>   1. Avoid man-in-the-middle modifications in transit: SSL addresses this.

This is still subject to DNS cache poisoning though the end user would
likely be presented with an SSL cert that would generate a security
warning. Pretty secure overall.

>   2. Make sure requests can not be replayed (Replay Attack): SSL again.

SSL does not defeat replay attacks.

A replay attack would be if I go and log in (using real credentials)
and you issue me a session cookie that identifies me as having been
authorized. At that point, I could copy the cookie and the urls from
the authenticated client and paste them into my own browser. These
would work just as well with http or https urls. The data would be
encrypted during transit but nothing about the transport mechanism
secures against the replay. The replay is predicated on your
authentication scheme.


> Now for the single sign on, again the third-party application requests a URL
> from my server.  Then the user is redirected to this URL. This URL bypasses
> my login screen and logs in the user, then issues a redirect setting a
> cookie and establishing a session.
>
> The risk here is that the URL is leaked.  So, my plan is to make a
> single-use URL that is short lived.  The idea is the third-party site should
> fetch the URL and it is only valid for a short amount of time (about a
> minute) and can only be used one time.
>
> Thanks -- and thanks even more if you actually read this far.

We are doing this using a token service that relies upon a shared key
infrastructure. When you do a login on Site A, Site A issues a request
to the token service and says "this user has authenticated on my site
and I want to identify this user to Site B as being able to access a
particular url over there" and then the token service creates a packet
that combines the users id, the url they are allowed to access and a
expiration for the token, then encrypts it using its private key, then
hands it back to Site A.

Site A can then send this encrypted packet over to Site B along with
the  url the user is requesting. Site B would have the Token Services
public key and be able to decrypt the token, check the url it contains
against the one requested and validate that the request time is within
what is accepted in the token, then log them in with the user id
provided.

There is still a chance of replay attack in this scenario within the
time period specified in token but it diminishes the chances. You do
have to set up public/private keyrings for each of the sites and share
public keys, so there is a bit more work on that side. But combine
that with strong SSL and you should be in pretty good shape.

Cheers,
Judah


More information about the thelist mailing list