1

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?

3

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.
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.

0

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.

  • How do come to the conclusion that a sub-domain is the same machine, or even on the same continent? technically all domains below .com are 'sub-domains of the '.com' domain. – LvB Feb 29 '16 at 10:32
  • @LvB - sub-domain means X.something.suffix. As long as all of your sites share something.suffix it will work because you can generate the authentication cookie for that sub-domain, and the browser will automatically pass it. All of the sites can be on different continents and it will still work. The sites do however have to share the same authentication DB (or at least have a mechanism for verifying the shared auth cookie, typically a shared authentication DB is used for this purpose). – TTT Feb 29 '16 at 14:49
  • In the Domain Name System (DNS) hierarchy, a subdomain is a domain that is a part of a main domain, Also in the security context, what is a Authentication DB? I surmise you mean an authentication Mechanism. lastly your doing a huge amount of assumptions about a system you simply do not know. for example its not even stated the 'application' is in fact a browser or another applications that utilizes cookies. Remember, not everybody is working on the same kind of applications as you yourself are. – LvB Feb 29 '16 at 15:25
  • Did you mean to point out something in particular in the wiki link? From what I can tell it has the same definition as sub-domain that I do. Also, the OP already said the "app" can read the cookies from the other site. – TTT Feb 29 '16 at 15:31
  • Yes, to get you to understand the Domain Naming Service. and what actually is a 'subdomain' a.k.a. a part of a domain. Like most people you seem to forget that the domains actually start from '.' or DNS Root, all TLD's are in fact sub domains of the Root domain ('.'). this means that the answer you give is much broader than you intended. – LvB Feb 29 '16 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.