Hacker News Reader

Comment by zelon88 | Hacker News Reader

Cookies are entirely a design choice, and a lazy one at that. It is entirely possible to identify, authenticate, maintain session, and store data about a user on the server completely without cookies. *

* https://github.com/zelon88/HRCloud3/blob/master/core.php#L54...

View on HN

They are just called "cookie banners".

The storage mechanism is not important.

Could you explain how, rather than linking to the middle of a large chunk of code? Fundamentally you need to have some way to associate the data on the server to a particular client, and cookies (or something like them) is the way HTTP does that. In particular, your link appears to be using PHP’s $_SESSION, which... uses a cookie.[1] (Or a URL parameter, but that’s usually a much worse idea than cookies, especially for something that’s handling logins.)

[1] https://www.php.net/manual/en/session.idpassing.php

PHP doesn't have to use a cookie to maintain session.

Check my other comment for an explanation.

Session information is usually stored in a cookie. It is not better to use a session URI parameter.

In the proof of concept I linked, a self expiring session token is given to the client.

If it is returned before the expiry, a new token is generated and the process starts over.

If it is not returned before its expiry the session is considered to have been closed.

But how are you storing the session token in the browser?

In a hidden DOM on the page. Updated asynchronously.

There is Javascript running on the page that updates the DOM.

So as long as the user is on the page, the "session" stays alive.

A session by definition extends beyond one page.

With some nastiness, you could make every link on the page a form submission and submit the session ID with the form. Then render it into the HTML that’s returned in response.

A rose by any other name would smell as sweet.

I see you edited your original comment rather than replying to mine.

The URI parameter must be accompanied by the session token and encrypted login credentials as well via POST.

So unless you steal the username, hashed password, tokens, and URI parameter before the expiry of the token then you aren't hijacking a user session.

Basically the web app builds a fingerprinting cookie with a super short lifespan in the page as a hidden DOM. On a set schedule, or with every request, the credentials that are baked into this "DOM cookie" are rotated. When the user stops sending requests the session is closed.

Let's say the cookie expiry is 10 seconds, or until the user clicks a button on the page.

Any MITM attack is going to have to intercept the HTML over clear text http in order to steal the DOM cookie. That attack would also work on a regular cookie. But with my design the attacker only has 10 seconds to deconstruct that cookie and use it to steal the session. With a regular cookie they have a lot more time.

The only other way to hijack the session would be local malware or browser extension, which would also work on a regular cookie.

The only difference between your “DOM cookie” technique and a browser cookie is that it sounds like you’ve (re)invented a session cookie that only works with single-page apps. Either way it boils down to an opaque session ID token which is stored on the client and sent to the server with every request. You could do the same expiry/crosschecking/validation on the server either way; it makes no difference for security how the client stored it.

Frankly, this entire codebase is full of code smells that are hallmarks of Dunning-Kruger security (I should know, I was like that myself once!) and the fact that you haven’t learned anything in the 3 years since it was written is alarming.

So my original comment was accurate then?

> Cookies are entirely a design choice, and a lazy one at that. It is entirely possible to identify, authenticate, maintain session, and store data about a user on the server completely without cookies. *

By your logic, you're just to lazy to do this better than me and it's just easier to throw banners at everyone?

Yes, it’s a design choice, in that you have chosen to design something worse for the sake of feeling industrious.

There is no need to show a consent banner for authentication cookies (these are considered “Strictly necessary cookies... essential for you to browse the website and use its features, such as accessing secure areas of the site”). On the flip side the directive on tracking consent covers any method of tracking, it doesn’t let you go “nyah nyah, I didn’t use a ‘cookie,’ I made my own and called it something else!” so if you think you would need a banner for a cookie, you will need a banner no matter how you do it.

I edited it about 10s after posting it.

Reply on news.ycombinator.com