Shoppers and Cookies

[phppete]

Does anyone know if regular online shoppers (e.g people who will most likely pay online) usually have cookies or at least first party cookies enabled?

Reason I ask is because I am coming to the last week of development of my new new cart system and I am wondering whether to disable session URLs and use session.use_only_cookies .

Obviously I don't want to risk sales but it would be rather nice to not have to worry about session hijacking.

Pete

[Syneryder]

I buy a quite a lot of stuff online and I'm one of those people who prefers to surf with cookies off. But I don't mind turning cookies on if I'm going to buy something - if you can pop up a little notice for me that says "you need to enable cookies" then I'm more than happy to turn them on. (I'm not claiming to be representative of all people online, just providing a data point for you).

I know that some popular payment processor systems like eSellerate require cookies to complete a purchase.

[Rich]

Does anyone know if regular online shoppers (e.g people who will most likely pay online) usually have cookies or at least first party cookies enabled?

I have found that many shopping carts require that cookies be enabled in order to operate. This means that *some* people--the people that shop *frequently* online--are accustomed to having cookies turned on in order to use a shopping cart.

However, remember this: if you require cookies, you will lose sales! What is the lifetime value of a customer to you? Now, how many sales do you need to lose per month before it "matters?"

I am wondering whether to disable session URLs and use session.use_only_cookies
I wouldn't recommend this. This just makes the BuyNow -> ThankYou process more complicated...and anytime things become more complicated, the conversion rate goes down and/or the abondonment rate goes up.

Note that "session URL's" only need to be used in areas where forms are not used. In the form areas you can use hidden fields for the session id. However, how visible they are is only a cosmetic issue.

Obviously I don't want to risk sales but it would be rather nice to not have to worry about session hijacking.
You won't only risk sales, you will actually lose sales! The more traffic you have and the higher the profit margin on the products you sell, the more money this will cost you.

There is really little to no risk from session hijacking. A good session id generator does not produce guessable ids. Besides, even if I were capable of hijacking an id there should be NO personally identifiable information (other than a userid) or sensitive information contained in either the session data or the cookie. If ANY sensitive information needs to be retained, then this information must only be accessable by an authenticated (login/password) user/customer.

At most, the only thing a "hijacked" session would produce is a shopping cart already filled with a bunch of items. :)

Hey, there's a really neat marketing idea that might actually result in some sales. Every time someone abandons a cart, leave the cart "lying around" on your home page and offer visitors to "pick up a cart someone left unattended". People are naturally curious about what other people might have placed in their carts. Then, when the user "picks up" the cart you just make a copy for the user and offer to go Checkout any or all of the items that were found in the cart...

[Randall]

Originally posted by Rich:
Every time someone abandons a cart, leave the cart "lying around" on your home page and offer visitors to "pick up a cart someone left unattended". People are naturally curious about what other people might have placed in their carts. Then, when the user "picks up" the cart you just make a copy for the user and offer to go Checkout any or all of the items that were found in the cart... Puts a whole different spin on the "people who shopped for X also shopped for Y" thing. Cute idea. :)

Randall

[phppete]

Hi Rich,

Thanks for your reply. Session hijacking can be a problem but I'll just ensure it isnt. At worse a malicious user could access a customers account but no CC details.

However now that I have decided to allow session ids in the URL I will ensure users are automatically logged out and that a user can only be logged in once as well as a few other counter measures.

Note that "session URL's" only need to be used in areas where forms are not used. In the form areas you can use hidden fields for the session id. However, how visible they are is only a cosmetic issue.

PHP does that for you apart from when using header("Location.... then I will just add some code to pass the session id if the user has cookies disabled.

even if I were capable of hijacking an id there should be NO personally identifiable information (other than a userid) or sensitive information contained in either the session data or the cookie.

I wouldn't agree there, a hacker can assume the identity of the user but like I say I will put measures in place to prevent that based on various criteria. Its not difficult just gives me another class to write.


Hey, there's a really neat marketing idea that might actually result in some sales. Every time someone abandons a cart, leave the cart "lying around" on your home page and offer visitors to "pick up a cart someone left unattended". People are naturally curious about what other people might have placed in their carts. Then, when the user "picks up" the cart you just make a copy for the user and offer to go Checkout any or all of the items that were found in the cart...


That is an interesting idea, a slight twist on that would be a 'Items the last 10 users put in their basket'. I am already adding the usual 'amazon' like stuff like users who bought x bought y and 'you may also be interested in xyz'.. the only probably with this new idea is a sense that a record of your actions on the site has been recorded, which may make some people feel a little nervous.

Thanks to Syneryder for your comments, its useful to guage other peoples surfing behaviour.

Pete :)

[Rich]

I wouldn't agree there, a hacker can assume the identity of the user ...
If properly designed, the only way someone could assume a user's identity would be to know the username AND password of the user's account. This also assumes that once the point of authentication is reached you are using SSL connections.

[phppete]

I agree to an extent but if I login using my username and password, a session var is set to keep the state between pages. My unique session id tells the script that I am logged in as Mr Smith for example. The usual auth script relies on sessions in PHP and doesn't assume Mr Hacker on another PC will be grabbing Mr Smiths session id. If Mr Hacker gets Mr Smiths session id then Mr Hacker becomes Mr Smith as far as the application is concerned.
There is a lot of information out there about session hi-jacking and session fixation, it is a potential problem unless you take into account that this could happen.

Pete

[Rich]

If Mr Hacker gets Mr Smiths session id then Mr Hacker becomes Mr Smith as far as the application is concerned.
But, how would the hacker obtain the session ID over a secure SSL connection? The risk here is very, very minimal, if any. To my knowledge, to date, no SSL session has ever been compromised.

[frankc]

Pete, FWIW I use CookiePal to monitor cookies and, unless shopping and I *know* why the cookie's being set, generally reject them. Still, I've enabled same-browser-session cookies.

[phppete]

Thanks for letting me know Frank.

Rich, what SSL cert would you recommend? Currently my user account pages dont have one, obviously that needs to change (not that CC details are held) but it will make it more secure.

The Thwaite one is $199 for a year, which one should I get?

What would you recommend?

Thanks

ete

[Rich]

The three certificates I recommend are Verisign, Thawte, and Geotrust (formerly Equifax).

[phppete]

Which one would you buy and why?

P