4 ms·

The only use for cookies I can see is authentication. There are other ways to authenticate that I have used that have been way less burdened by security issues.

The only use for cookies I can see is authentication. There are other ways to authenticate that I have used that have been way less burdened by security issues. Store an auth token in local storage and transmit it as the Authentication header for example: CSRF problems, works with whatever framework you want. Why do we still need cookies at all?

srfvtgb 6y ago
Can you do this without Javascript?
- lima 6y ago
  Nope.
- IgorPartola 6y ago
  My argument is that if you need authentication, the browser should have that built in as a first class citizen. And if you don’t want it, then why set cookies?
Null-Set 6y ago
Cross site scripting can exfiltrate an auth token stored in local storage. An HttpOnly cookie cannot be stolen this way, and with SameSite=strict, CSRF is not an issue.
- IgorPartola 6y ago
  If I am running code on your site as another user, I don’t really need to steal you auth token. But that is true. Which is why browsers should expand support for authentication to provide things like public key authentication, credentials/personas storage, etc. At the very least, an API to store auth tokens (and just auth tokens). Better yet, a standard login UI for logging into any given website. Even better, public key auth so that instead of logging in by typing in a username and password, you would select which persona you use from a drop down and passwords aren’t a thing. Of course that would require a robust and secure mechanism for syncing the personas/keychains across different devices and browsers.
cratermoon 6y ago
Cookies are used for all kinds of session state management besides auth. Your shopping cart, for example, depends on them. Without cookies, the server would have to send the entire state of the session in each response, and the client would have to send that entire state back on every request. Cookies allow the client and server to exchange only a small token that the server can use as a key to state storage. Even if you could shrink that state down to something reasonably small, it still introduces the problem of the client and server getting the state out of sync.
- ywei3410 6y ago
  I mean that's not really true - TCP allows a persistent connection so you could totally just keep the shopping cart for the duration of the time that the user is on the website and /not/ use a cookie.
  - monsieurbanana 6y ago
    Even if you were using a desktop computer, it seems unreasonable for both the website and most users to lose the cart information every time you put your computer to sleep. But it becomes much worse with mobile devices, such as a phone. I don't want to lose the state of my browser tabs every time I get into an elevator.
    - ywei3410 6y ago
      I'm not certain whether it's unreasonable or it's become an expected norm; you don't expect to be able to leaving a shopping cart full if you're leaving a physical shop, for example. I guess it very much depends on your usage - I wonder the proportion of users who add to a shopping cart and go back to it without creating an account. Of course, we're also ignoring session local storage, in memory storage etc... for alternate solutions.
      - monsieurbanana 6y ago
        Ah, yes, I was commenting on the TCP connection, which doesn't strike me as a solution. Local storage is another story and probably a good alternative to storing something server-side, at the cost of more back-and-forths to validate data isn't outdated. > I'm not certain whether it's unreasonable or it's become an expected norm; you don't expect to be able to leaving a shopping cart full if you're leaving a physical shop, for example. It has become the norm, which is why it's (IMO) unreasonable to change that. Realistically, for a solution to be doable it needs to allow for saving the cart state, as otherwise websites will simply resist the change.
tester756 6y ago
It's way easier to protect from CSRF - either via SameSite or Anti forgery tokens. Stealing tokens via XSS is way harder to solve.

srfvtgb 6y ago

Can you do this without Javascript?

lima 6y ago
Nope.
IgorPartola 6y ago
My argument is that if you need authentication, the browser should have that built in as a first class citizen. And if you don’t want it, then why set cookies?

Null-Set 6y ago

Cross site scripting can exfiltrate an auth token stored in local storage. An HttpOnly cookie cannot be stolen this way, and with SameSite=strict, CSRF is not an issue.

IgorPartola 6y ago
If I am running code on your site as another user, I don’t really need to steal you auth token. But that is true. Which is why browsers should expand support for authentication to provide things like public key authentication, credentials/personas storage, etc. At the very least, an API to store auth tokens (and just auth tokens). Better yet, a standard login UI for logging into any given website. Even better, public key auth so that instead of logging in by typing in a username and password, you would select which persona you use from a drop down and passwords aren’t a thing. Of course that would require a robust and secure mechanism for syncing the personas/keychains across different devices and browsers.

cratermoon 6y ago

Cookies are used for all kinds of session state management besides auth. Your shopping cart, for example, depends on them. Without cookies, the server would have to send the entire state of the session in each response, and the client would have to send that entire state back on every request. Cookies allow the client and server to exchange only a small token that the server can use as a key to state storage. Even if you could shrink that state down to something reasonably small, it still introduces the problem of the client and server getting the state out of sync.

ywei3410 6y ago
I mean that's not really true - TCP allows a persistent connection so you could totally just keep the shopping cart for the duration of the time that the user is on the website and /not/ use a cookie.
- monsieurbanana 6y ago
  Even if you were using a desktop computer, it seems unreasonable for both the website and most users to lose the cart information every time you put your computer to sleep. But it becomes much worse with mobile devices, such as a phone. I don't want to lose the state of my browser tabs every time I get into an elevator.
  - ywei3410 6y ago
    I'm not certain whether it's unreasonable or it's become an expected norm; you don't expect to be able to leaving a shopping cart full if you're leaving a physical shop, for example. I guess it very much depends on your usage - I wonder the proportion of users who add to a shopping cart and go back to it without creating an account. Of course, we're also ignoring session local storage, in memory storage etc... for alternate solutions.
    - monsieurbanana 6y ago
      Ah, yes, I was commenting on the TCP connection, which doesn't strike me as a solution. Local storage is another story and probably a good alternative to storing something server-side, at the cost of more back-and-forths to validate data isn't outdated. > I'm not certain whether it's unreasonable or it's become an expected norm; you don't expect to be able to leaving a shopping cart full if you're leaving a physical shop, for example. It has become the norm, which is why it's (IMO) unreasonable to change that. Realistically, for a solution to be doable it needs to allow for saving the cart state, as otherwise websites will simply resist the change.

tester756 6y ago

It's way easier to protect from CSRF - either via SameSite or Anti forgery tokens. Stealing tokens via XSS is way harder to solve.