[thelist] Single Sign On Security
Bill Moseley
moseley at hank.org
Tue Mar 2 18:48:17 CST 2010
Sorry, this is a bit wordy. In short I'm looking for pitfalls and security
issues you may be aware of when implementing Single Sign-On as well as
implementation suggestions. I'm aware of OpenID and OAuth approaches.
In this case we will create a custom implementation.
I have a subscription site -- people normally create an account and log in
with their username and password to use my site.
A third-party partner site wants to provide access to my site but bypass my
account creation and login screens. They want to have a sign-up form on
*their* site and then provide access to my site. My site will still need an
account created for each user first, so that means I need an API to allow
the third party site to create an account and then provide a way to redirect
to my site bypassing the login page.
I'm looking for ideas how to make this easy for the third-party site, yet be
secure.
Note that once the user's account has been created on my site (by the
third-party site) the user would be able to directly log into my site
avoiding the third-party site completely.
The process might go something like this:
1. User goes to third-party site and creates an account with a username
and password.
2. User logs into third-party site (if not part of the account creation
process).
3. User wishes to access services provided by *my* site via the
third-party site.
4. If not already done, third-party site uses a background API call to my
site to create an account on my site, passing along username and password.
5. Next, third party site makes a background API call requesting a URL to
access my site. My site creates the URL and returns it.
6. Third-party site sends a the end-user a redirect to this URL.
7. My site sees this URL and "logs in" the user, avoiding the login
screen.
8. End-user uses my site.
The biggest thing I don't like about this is that the end-user has given
their password to the third-party site, and now my site has that password.
Yes, OAuth is a solution for that problem. But, for now assume we don't go
that route.
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.
2. Make sure requests can not be replayed (Replay Attack): SSL again.
3. Make sure requests come from authorized user:
1. Can limit by IP address, although that only works if IP is static
and known, no proxies, etc.
2. Use authentication credentials (password/shared key)
Is that enough?
I've seen recommendations to have a shared key and then the third-party
creates a hash of some specific data in the request and then on my server
also compute the hash to make sure they agree. But, that seem redundant.
Seems SSL plus a password/secret in th e request achieves the same thing,
no?
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.
--
Bill Moseley
moseley at hank.org
More information about the thelist
mailing list