hi (:

I just implemented this pattern http://www.theserverside.com/patterns/thread.tss?thread_id=31258 on top of PHP's in-built session handling functions.

I have single sign-on (SSO) and single log-out (SLO) working across several domains. Functionally, I'm very happy with it but I'm concerned about security.

So far, I've implemented session ID regeneration on all changes of privileges as well as on fresh sessions. Only the "master" domain ever (re)generates the session ID, passing it on to the slave via a http redirect (if requested).

The master will never redirect outside its list of valid slave domains. And if a slave receives a session ID in the query string, it self-redirects to strip it out... so the ID should hopefully stay out of referrer logs.

I'm wondering if this is any less secure than just using PHP's in-built session on a single domain?

Edit: I should mention this is not SSO across different webapps, it's a single application and userbase that spans several second-level domains.

All advice/abuse appreciated!

thanks!
shy (:



Edited 1 time(s). Last edit at 10/13/2007 08:13AM by shyguy.

i'd really love to hear someone's thoughts, no matter how small.. even if it's just a link to a more appropriate place to discuss this. sla.ckers.org is the most suitable place I've found so far..

anyway, would love to hear back from some of you

thanks
shy (:

I haven't read the pattern you linked to, so this may or may not be relevant, anyway; I do not see why a SSO system is necessary, if you've just got distinct subdomains.

All you would need to do would be to set the cookies to .domain.com rather than just domain .com and then the cookies would be sent along with the request for all subdomains.

This can cause further issues with an XSS condition on *any* subdomain being potentially devastating, though that can be mitigated by adding an additional authentication cookies to specific subdomains such as settings.domain.com so that major changes can only occur from that domain, and with those specific cookies.

Having said that, if you envisage some need for SSO across multiple domains, then the method you described is the best method, though I would recommend using a different token for each application, so that an XSS in one application does not lead to the compromise of another.

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]

hi kuza55

it is actually several .com's hence the extra measures, and fortunately it is a single application.. which hopefully means: if there's XSS is one, it's in available on all the other domains anyways.

i think for serious changes i will do as you said and lock it to one host (SSL), and require re-authentication.

the current system is cookie-only PHP sessions without SSL auth.. just wanted to make sure I'm not introducing a huge security hole.. i was a bit iffy about passing the SID in the URL (brief as it may be!)

thank you for your input (:

I just skim read this, so might be off track... why do you need to persist the session via the browser based parameters anyway? Use a server side or other 'out of band' communication. For example, maintain session in a common database (you said its the same app, right? )

serachewhi Wrote:
-------------------------------------------------------
> I just skim read this, so might be off track...
> why do you need to persist the session via the
> browser based parameters anyway? Use a server
> side or other 'out of band' communication. For
> example, maintain session in a common database
> (you said its the same app, right? )

Hi serachewhi, thanks for your input!

I'm not sure I fully understand what you mean. Would you mind going into more detail?

It is the same app, yep, and sessions *are* stored in the database. The only information being passed through the browser is the session ID itself as would be the case with a "regular" session.

thanks!
shy (:

OK no sorry I was way off track, don't even know what I was referring to now I see you are managing several .com's... session id is the only way. Think I thought originally you were passing all the parameters and re-establishing the session that way..

Don't forget to handle csrf issues