What are the problems of httponly and secure cookies?

Question

We would like to set:

1. all our cookies (session id, etc.) as "httponly"
2. all security (session token, "remember me", etc.) cookies as "secure"

Except compatiblity issues, what are the know problems to use httponly and secure cookies?

Does Google bot support/like them? Are there some blocking issues/bugs with some browsers?

I have seen well known websites not using "httponly" and "secure" for important cookies. Negligence? Technical reason?

Note 1: the question is not related to security. We know why we need to set "httponly" and/or "secure". But as some well known websites not using https do not set these 2 attributes on sensitive cookies, we were trying to understand which reason is more important than security (compatibility, bug, SEO, etc).

Solution

It really depends on the data you are storing. If your site doesn't use an SSL cert this is easy. Everything would go in httpOnly cookies or session variables. You would decide that based on whether the data you were storing is sensitive. If it's storing the user background color choice then httpOnly is really always fine. It it's storing something which could potentially be dangerous in the wrong hands then you want to use a session. The session ID itself doesn't need to be encrypted though.

The problem with secure cookies is that they can be cracked with enough time. For this reason they are never considered good for high security. That being said, they do offer a sort of medium security that when properly used can save your server resources. If you have a reasonably well powered server then I would suggest sticking to session variables. But in the right situation a secure cookie is useful. If your app needs a lot of client side data (from a ajax DB front end for example) then storing that data in a secure cookie which expires at the end of the session may be a great idea.

A good rule of thumb is that if the page needs to use SSL then so should the cookies. The cookies are no less secure than the page. That goes for httpOnly and secure cookies. Also, secure cookies are a greater security risk only when they don't expire because that give a potential hacker longer to find them.

UPDATE: Negligence seems likely but it could also just be because the server is overburdened and it'd be too much overhead to run SSL for all of that. This seems unlikely though because modern CPUs have dramatically sped up SSL encryption. I do think that there is a limitation in that if the user is accessing your site using http then secure cookies will not be visible (or at least wont always work in all browsers). I've had trouble with that in the past but others seem to think that it works fine. Personally, I use SSL on nearly every site I run where someone has to log in; just to be safe. It probably isn't the greenest thing to do but makes me sleep better. I'd say that as long as you can do it you should use SSL and secure cookies and always use httpOnly unless you can't.

And as another poster has already mentioned search bots typically ignore cookies. You can check for GOOGLEBOT in the request header to display content to Google as if it is logged in (but that sort of defeats the point of hiding content until someone logs in).

Comments

[Toto]

Google has a lot to do with cookies when crawling. To be clearer about he last point, I was speaking about session hijacking/fixing.

[Toto]

Thank you for your answer and sorry for my question not being clear enough. I have added a note to clarify it.

[Toto]

A session id cookie must at least be httponly and secure to prevent session hijacking. So why is SO not using secure for exemple?

[Bobby Tables]

@Toto - Because they do not use HTTPS at all. You cannot use the Secure flag on a HTTP site, the cookie would not be sent back by the browser and you would loose the session. And yes, a site cannot be secure without HTTPS, but SO is not considered to be a site with critical data, and SSL is not for free.