5

I was reading how the infamous TorMail had a legacy mode that allowed their email service to be used without cookies. The article implied they did this for privacy concerns for end users. From what I understand, it's not possible to store sessions without cookies. So I have to ask:

  1. How do people not use cookies, do they use PHP sessions or something similar?

  2. If we don't need cookies, why use them?

  3. What is the security/privacy benefit of avoiding them?

  • There are several options for sessions without using cookies. Sessions need a session-token that is communicated between the client and the server; any method of communicating said token will do (although some are notably less secure than others). – Jacco Apr 4 '17 at 6:52
  • As a fallback, if the client is unable to use cookies, some application servers encode a session variable either in the URL or as a hidden variable. – munchkin Apr 4 '17 at 14:54
2

Why cookies, and what are the alternatives?

HTTP is stateless. A webpage that remembers you (so you don't have to reenter your password every time you visit a new page) is stateful. To bridge the gap between the stateless protocol and the stateful applicaiton you need some kind of session identifier that is included in every request.

The standard way to do this is with a cookie. But you could put it anywhere in the HTTP request. Some examples:

  • A common practice back in the day was to put the session identifier in the URL, but this meant it ended up in all sorts of logs and leaked via the referer header. Not so good.

  • A single page app could just store the identifier (e.g. an authentication token) in a JavaScript variable on the client, and then send it in a custom header with every request. It would be like a cookie that only lives for one page load. (As Marko Vodopija points out, the security would be somewhat weaker here, since the identifier could not be protected by http-only like a cookie can.)

You can think of these as different ways of "simulating" a limited version of a cookie.

PHP uses cookies for its sessions, by the way.

Why do some people dislike cookies?

There is nothing inherently insecure about cookies, and using them is not less secure than any of the more contrieved alternative methods. On the contrary, as we have seen, some replacements are worse.

The reason some hate cookies is the same reason they are so useful - they make the web stateful. This means that they can be used to track you, with all the privacy implications that comes with. So some might want to disable cookies completely.

That is probably the reason why a privacy focused site would offer a cookie free alternative. It doesn't make the site itself any safer, but it can service users who have cookies turned off for privacy reasons.

  • Thank you for your answer. Is there any secure alternative to cookies? The reason I can see them fading is because of all the third party trackers. – Dylan Apr 4 '17 at 8:34
  • Unless you have a significant amount of users with cookies turned off I would not care about it. As I say, using cookies does not make your site less secure in itself. That said, I see no security problem with the approach described in the second bullet point. – Anders Apr 4 '17 at 8:38
  • @Dylan I would see one problem with second option: if authentication token is meant to be protected from stealing, using httpOnly cookie is better option than storing it sessionStorage on the client. httpOnly cookie is not (theoretically) readable from JavaScript and thus (theoretically) imune to be stolen by XSS. It is vulnerable to CSRF though but this can be mitigated. I would argue that not using httpOnly cookies would make a site less secure and not more secure. Anders, would you agree? – Marko Vodopija Apr 4 '17 at 14:34
  • @MarkoVodopija Yes, good point. Will update the anser - thanks. – Anders Apr 4 '17 at 14:37
  • @MarkoVodopija What if in the second option, the session id is stored in a Javascript variable inside an SPA. Wouldn't this solution be safer than the session cookie one? – mljrg Jun 13 at 12:14
1

Just a complement to @Anders's answer.

Cookies are one way to have stateful sessions in HTTP which by itself is a non connected stateless protocol. Sessions are necessary for web applications, and any in line business.

Cookies used to be frowned upon as was javascript in the early times, because first is a way to collect usage statistics and has privacy concerns, while the other allows the server to control the browser, which has security concerns. Nowadays, many sites are simply not useable with cookies or javascript disabled, and disabling them in a browser is not always a trivial task. So my opinion is that is fine to provide a service requiring cookies. Just display a warning page saying that your service requires cookies if you cannot establish a session.

URL rewriting is (was?) an alternative to cookies to provide sessions in HTTP. In that mode, you consistently add a parameter consisting of a key and the session identifier. All session data should be carried server side in that mode. That way there is no additional risk of data leakage because only the identifier is exchanged in the URL. The downside is that it is not bookmark friendly: the URL does contain the session id, so if you bookmark the URL of a page including it, you will get an invalid session error when you try to use it later. And it is much harder to use than a cookie to pass information between sites of same domain. For that reason cookies is now the standard way to have a stateful HTTP site or application.

People that do not like cookies will also argue that as there is no persistent equivalent in URL rewriting, and that persistent cookies are highly used to collect data on client behaviour, major Web companies (Google, Facebook, Amazon, etc.) willingly only allowed cookies to browse their sites, and that because of that URL rewriting has been more or less abandoned. Be it true or false, it is just now meaningless because the fact is that cookies are required by most sited and allowed by most users.

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.