Sessions + cookies + different domains

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
Parin
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 7:36 am

Sessions + cookies + different domains

Post by Parin »

Hi,

I'm currently working on a website which consists of two parts:
- the non-secure, browsing part
- the secure part, for placing orders, managing user account, ....

Now, the big issue here is, is that the secure part is on a different domain.
This is quite important, and I'll elaborate further in a minute.

In the past we used to use session and user cookies, for authentication, but since a lot of customers complained about the cookies not working (it was always their side that had the error :roll: ), I decided to switch to the $_SESSION method from PHP. This seems to work just lovely, and I'm quite pleased about the results. Even though it took me a while to figure out how to carry the session id from the non-secure to the secure domain, I figured this out eventually, so no problems there.

But, now, I've been asked to give the customers the option to remain logged in permanently because our frequent visitors do not want to log on each time they close and reopen their browser window. In order to do this, I place a user cookie with an md5 hash.

And now we finally come to the problem, when a person arrives at the log on window, he will be on the SSL domain. If the log on is succesful, the cookie is set for that domain.
If that person then continues browsing, he'll eventually end up back on the non-secure domain, at which point, I will set the cookie there as well.

However, should that person not return to the non-secure part of the website and close his browserwindow after logging on, the cookie will only be available for the SSL domain. When the user then reopens the website, he will start again on the non-secure domain, but since the cookie was never set there, he is not logged on even though he said he wanted to remain logged on permanently. This will of course create massive confusion among our customers.

I can only think of two options, but I do not like either of them.

1) after logging on, redirect the users to the non-secure domain, set the cookie and immediately redirect them back to the secure domain. (so this would be invisible to them)
I do not like this because:
- the server load will increase significantly
- malicious users might be able to use this redirecting to create a loop and bring down our servers.

2) log the person on, on the non-secure part of the website, place the cookie and only then redirect them to the secure domain where at that point the cookie will also be set.
I do not like this because:
- the username/password will be sent unencrypted and can easily be sniffed out, so it kinda destroys the whole concept of having a secure logon procedure.

So, as you can see, I have not yet found a solution to this problem, so therefore I turn to you guys ;)

Perhaps someone has any ideas? I have done a great deal of reading about 'hacking' cookies to different domains (using 1x1 pxl images and what not), but as I understand it, these are considered third-party cookies and most browsers disable these by default nowdays. So this doesn't seem like a solution to me either.

Any input would be greatly appreciated.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

First and foremost, what you are describing - without more detail (and I hope you can clarify) - is not a secure login system. I might be wrong! But you don't give enough information about how the md5 cookie is generated, validated, and placed to be clear on how secure it is.

That being sad, you asked for a specific issue and resolution, so let me respond to that.
Parin wrote: 1) after logging on, redirect the users to the non-secure domain, set the cookie and immediately redirect them back to the secure domain. (so this would be invisible to them)
I do not like this because:
- the server load will increase significantly
Signifigantly might be over-stating it considerably. At most, the redirection page would simply contain a check for their credentials (make sure the cookie exists), and then a cookie/session routine. In both cases, thats trivial - even at the million user mark. So, thats a bit of an exaggeration.
Parin wrote: - malicious users might be able to use this redirecting to create a loop and bring down our servers.
Thats easy enough to prevent - either watch IP's, use proper http response codes (unchanged content shouldnt reload), or only redirect if a valid cookie is present - which would require them logging in in the first place, slowing them down considerably.

So thats a valid, possible solution. However..
Parin wrote: 2) log the person on, on the non-secure part of the website, place the cookie and only then redirect them to the secure domain where at that point the cookie will also be set.
I do not like this because:
- the username/password will be sent unencrypted and can easily be sniffed out, so it kinda destroys the whole concept of having a secure logon procedure.
Correct - however, you CAN include (via iframe, frames, or other monstrosities) the insecure domain IN the content of the secure domain - allowing you to set cookies from both on the same page. However, depending on their IE settings, and version, it may flag with a warning.

So, the specific issue you mention - I suggest an iframe, or a redirect. Both should work fine, although I certainly hesitate to call it a secure login - would need more detail on the current login sequence.
Parin
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 7:36 am

Post by Parin »

First and foremost, what you are describing - without more detail (and I hope you can clarify) - is not a secure login system. I might be wrong! But you don't give enough information about how the md5 cookie is generated, validated, and placed to be clear on how secure it is.
Well, the user sends his username/password through a form login, which is then validated against the values in our db. If the password matches, an MD5 string is generated and set as a cookie. That MD5 value is also stored in our db in the customer record. Then, when the customer returns, we'll look for the value of his cookie in our db. If we find it, he is auto logged on, if not, he'll have to log in manually.

As for making it all much more secure, I'm very interested in learning all this, but all I can usually find are the simple, basic login methods. Either, or the really advanced tutorials which usually boggle my mind ;)
Perhaps there are books to recommend?
Signifigantly might be over-stating it considerably. At most, the redirection page would simply contain a check for their credentials (make sure the cookie exists), and then a cookie/session routine. In both cases, thats trivial - even at the million user mark. So, thats a bit of an exaggeration.
Well, my server administrator discouraged this idea because of that reason. So I believed him :oops: .
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Parin wrote: Well, the user sends his username/password through a form login, which is then validated against the values in our db. If the password matches, an MD5 string is generated and set as a cookie. That MD5 value is also stored in our db in the customer record. Then, when the customer returns, we'll look for the value of his cookie in our db. If we find it, he is auto logged on, if not, he'll have to log in manually.
Thats what I thought.

The problem with that design is that it doesn't protect against replay attacks. In other words, if I can 'sniff' the connection between "good user" and your server, I can grab the md5 value he is sent.

With that, I can create my own cookie, and login as him. Simple as pie.

Thats the problem with "persistent" logins without authentication - it reduces the security down to the cookie - which is sent plain text.

It wouldnt be so bad if it was being sent ONLY on the ssl side, but you made it clear that the md5 cookie (the persistent cookie) is sent from the insecure side.

It's not very challenging these days to sniff a network segment. Its also trivial to 'bake' your own cookies. Net result? Not very secure.

There isnt an easy solution though - you are choosing between security and convenience. EITHER its secure (per-login credential checks, ssl-only), OR its convenient. It all depends on what you are trying to defend.
Parin wrote: As for making it all much more secure, I'm very interested in learning all this, but all I can usually find are the simple, basic login methods. Either, or the really advanced tutorials which usually boggle my mind ;)
Perhaps there are books to recommend?
There are many - too many. :) My day job is in Information Security, so I've done this professionally for over 4 years.. I couldn't begin to rattle off WHICH books were the most helpful.

The net is your friend - google for CHAP login, and read the links in my md5 tutorial. Those should be a solid start.
Parin wrote:
Signifigantly might be over-stating it considerably. At most, the redirection page would simply contain a check for their credentials (make sure the cookie exists), and then a cookie/session routine. In both cases, thats trivial - even at the million user mark. So, thats a bit of an exaggeration.
Well, my server administrator discouraged this idea because of that reason. So I believed him :oops: .
So, put it to the test. Code talks louder than theory. I absolutely may be entirely wrong. There are .. dozens of factors that could change the situation. Low memory, high memory, millions of users, or a few very-high-activity users. Never know.

Thats what testing is for.
aleigh
Forum Commoner
Posts: 26
Joined: Thu Mar 25, 2004 11:06 am
Location: Midwestern United States
Contact:

Post by aleigh »

As Roja did a great job pointing out, the network is basically unsecure unless SSL is used. And as has already been pointed out you really have to scale your security in proportion to what you are trying to protect.

Now that I have said nothing new, I would like to offer two things; one is that you consider the best practicies that other companies do. For example amazon lets you automatically log in, but does not allow you to do something "serious" such as change your password, update your account information, or purchase an item without your password. So you might consider this concept, it has worked well for me in the past; the idea that you recognize the person using an insecure means but require authentication that is session-specific to perform certain activities.

Second was have a look at what Visa has to say; Visa has their CISP program, part of which falls to securing online transactions. They are obviously on one extreme as far as requiring encryption and security but some of their information is quote interesting on it's own. I am sorry I do not have links offhand but I know they have several whitepapers and manuals available on their website that cover how to structure practicies and websites for taking Visa transactions and some of this information might apply to you.
Parin
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 7:36 am

Post by Parin »

Thanks for the links and the insight Roja.
I will check out your tutorial as well.


aleigh, that is indeed a very good suggestion. I will bring that up during our next meeting.
lostboy
Forum Contributor
Posts: 329
Joined: Mon Dec 30, 2002 8:12 pm
Location: toronto,canada

Post by lostboy »

Are the domains part of a master domain (like http://www.mysite.com, secure.mysite.com, smtp.mysite.com)?

If the above is true, you can set the cookie to be shared across domains like above by setting the domain criteria in the cookie to ".mysite.com"
Parin
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 7:36 am

Post by Parin »

unfortunately they are not.
yeah I know, sounds silly, but that's how they want to do it here. (SSL certificates aren't cheap apparently)
Parin
Forum Newbie
Posts: 8
Joined: Thu Mar 25, 2004 7:36 am

Post by Parin »

Thats easy enough to prevent - either watch IP's, use proper http response codes (unchanged content shouldnt reload), or only redirect if a valid cookie is present - which would require them logging in in the first place, slowing them down considerably.
Could you please tell me some more about those http response codes? I find it quite hard to understand all these http header settings.
Post Reply