Authenticating user in same sub-domain using cookies

Question

We have few in production websites say site1.dom1.com , site2.dom1.com , site3.dom1.com which are just replicas working on different server.

Now we want to extend some application on another server say app.dom1.com (Note: I don't have access to sessions stored in site1, site2 and site2) which would require authentication (if user is logged in in any of the site1/site2/site3 ), he/she should be able to access app.dom1.com

Now we don't want app1 to interact with any of the other sites.

We have thought of generating signed cookies from site1 , site2 and site3 which we can decrypt at app using same secret_key (which is used for generating the signature) and check for a particular phrases and a valid timestamp.

Now, how far is this method secure. How often should I change my secret key , and is it a good way for authentication? If it is vulnerable, how?

Answer 1

You could generate a session token that is purely client-side using JSON Web Tokens.

The secret can be shared between your subdomains that authenticate and your app. The secret is used to generate a HMAC over the claims in the token - note they do not need to be encrypted unless you want to hide the data from the user themselves - the HMAC prevents parameter tampering because the end-user does not know the secret to regenerate the HMAC.

Note that sharing cookies over different subdomains can be insecure unless you completely trust every site that is running in a subdomain. This is because the Same Origin Policy for cookies is lax and does not consider a different subdomain or protocol as a different origin. This same "flaw" is what enables you to share authentication, however this might not be right for you if you don't control all sites or have the same security applied to each site (a weakness in one can undermine the security of them all). Possible exploits include session fixation and session hijacking should any vulnerabilities exist in any of the sites on the main domain (even XSS or CSRF).

If this is a concern, use OpenID or OAuth instead of this method.

It is also good practice to set the Secure flag on authentication cookies, and use HSTS to protect the cookies from insecure transport mechanisms (i.e. plain HTTP).

Also be aware that JWTs have the following weaknesses:

• They cannot be revoked server-side because they exist purely client-side.
• All a logout function can do is delete the cookie, it cannot prevent an attacker that has captured a cookie from continuing to use it to hijack a session.
• Any change of password will not logout existing sessions for that user, increasing exposure in the event of any password breach.

Answer 2

There is an old axiom in the Security branch "Do not roll your own", as its often much easier to introduce security openings than it is to close them.

I would always use a Internet standard like Oauth 2 for these type of setups (share users over multiple websites) especially when no direct interaction is desired.

As to how secure your current proposal is. no idea. I mis almost all information to make a informed decisioned on security for this system. and it is unlikely we can do anything else but give some pointers to watch out for.

Answer 3

The key here is the same sub-domain of dom1.com. When that is true you usually have the option of sharing the same authentication DB too, and if so, logging into any one place will write a cookie that can be used in all places. The trick is to make sure you set the cookie domain to be:

dom1.com
(or .dom1.com for very old browsers)

Now the auth cookie will automatically be sent when visiting any of the sites. You will not need to share sessions for this to work, only the authentication DB. Each site can still have it's own separate DB that handles the logic particular to that site.