6 ms·

> You as a user can delete, modity, edit, hack them to your heart's content. This is not true in practice though. Cryptography means they cannot be altered (or

> You as a user can delete, modity, edit, hack them to your heart's content. This is not true in practice though. Cryptography means they cannot be altered (or even read) if their creator doesn't want them to be altered. Of all the CRUD operations, users can only realiably delete the cookie.

NBJack 1y ago
I gotta ask: how many cryptographically secure cookies have you encountered? In theory, yes. In practice? That's kind of expensive.
- zeroCalories 1y ago
  If you wanna do any kind of restful service securely you need to sign your data.
  - jkrejcha 1y ago
    There's nothing about that that requires JWTs/signed cookies. You may need JWTs or their moral equivalents for 3rd party services but, especially for 1st party services, session identifiers are a fine enough scheme that are oftentimes implemented more securely and have the same amount of statelessness (at least from a REST perspective) as a JWT. Not that cookies are allowable within the constraints of REST anyway due to violation of the uniform interface/stateless constraints, but pragmatically cookies have the most user agent support, and when used as just an session identifier, are relatively close to following the constraints and are much better supported than using the Authorization header or whatever[1]. Statelessness (the lack of "sessions") refers generally to the fact that the client and the server don't need to share state, i.e. the client has all it needs to make a request rather than, like, an "authorization context" or something (which is what a "user session" colloquially is). Unfortunately, the difference in the way the terms were used kinda led to this confusion which made people think that they weren't doing REST unless they were using JWTs or signed cookies. It's the difference between storing the shopping cart in a cookie or what have you vs. creating a shopping cart resource. In the former scenario, the server has to track where in the (often implicit) state machine the current client is[2], whereas in the latter, the client has all it needs (a URI, authz token, etc) to make the request and all the state is stored server-side. [1]: If browsers had better support for setting the Authorization header somehow, this would almost certainly just be a "best practice" that we take for granted. Automated clients with API keys tend to be better in this regard. [2]: And there are significant disadvantages to doing it this way, if you've ever lost your cart or got those weird "session expired" errors after hitting the back button, you've ran into the pitfalls of doing it this way.
- rileymat2 1y ago
  As far as preventing editing, but not reading, JWTs are very common.
- briHass 1y ago
  Anything on the ASP.NET stack has it in forms auth tickets and role cookies. You could store additional data in the forms auth one, and it auto-rotates the encryption at half the session length. One of the best authentication libraries at the time.
  - mubou 1y ago
    ASP.NET is so underrated. It's by far the most comprehensive and adaptable web framework I've ever encountered.
    - solardev 1y ago
      Microsoft's developer experience is often world class. If they hadn't burned so much goodwill in the 90s and 2000s through embrace, extend, extinguish, they might have won (or at least stayed relevant) through the Web wars. It's still hard to trust them today, for me at least.
      - mubou 1y ago
        The fact that we're both being downvoted without a reply/explanation is a testament to that, it seems :( I can't imagine anyone who's actually used it responding that way.
- dudeinjapan 1y ago
  Many web frameworks like Rails allow you to easily fully encrypt (make unreadable to browser) or sign (make readable but not editable) with a server-side key. Some pen testers will report unsigned or unencrypted cookies so I imagine its quite common.
- 3np 1y ago
  Storing JWTs as cookies is not that rare in practice.
- Fire-Dragon-DoL 1y ago
  Rails encrypts them too, or sign them, one of the two. Either way, you cannot tamper them
- franga2000 1y ago
  They used to be the norm in Django, Flask, RoR and ASP.NET, which made up the majority of the non-PHP web. These days database queries are cheap enough that most new sites just use session tokens, but that's also not something you can modify (well, besides transplanting it from a different session).
creatonez 1y ago
> Of all the CRUD operations, users can only realiably delete the cookie. I mean, one other operation I can think of is swapping a cookie out for a different one, so you can have two separate sessions managed independently... Which is essentially what Firefox's container tabs are.

NBJack 1y ago

I gotta ask: how many cryptographically secure cookies have you encountered? In theory, yes. In practice? That's kind of expensive.

zeroCalories 1y ago
If you wanna do any kind of restful service securely you need to sign your data.
- jkrejcha 1y ago
  There's nothing about that that requires JWTs/signed cookies. You may need JWTs or their moral equivalents for 3rd party services but, especially for 1st party services, session identifiers are a fine enough scheme that are oftentimes implemented more securely and have the same amount of statelessness (at least from a REST perspective) as a JWT. Not that cookies are allowable within the constraints of REST anyway due to violation of the uniform interface/stateless constraints, but pragmatically cookies have the most user agent support, and when used as just an session identifier, are relatively close to following the constraints and are much better supported than using the Authorization header or whatever[1]. Statelessness (the lack of "sessions") refers generally to the fact that the client and the server don't need to share state, i.e. the client has all it needs to make a request rather than, like, an "authorization context" or something (which is what a "user session" colloquially is). Unfortunately, the difference in the way the terms were used kinda led to this confusion which made people think that they weren't doing REST unless they were using JWTs or signed cookies. It's the difference between storing the shopping cart in a cookie or what have you vs. creating a shopping cart resource. In the former scenario, the server has to track where in the (often implicit) state machine the current client is[2], whereas in the latter, the client has all it needs (a URI, authz token, etc) to make the request and all the state is stored server-side. [1]: If browsers had better support for setting the Authorization header somehow, this would almost certainly just be a "best practice" that we take for granted. Automated clients with API keys tend to be better in this regard. [2]: And there are significant disadvantages to doing it this way, if you've ever lost your cart or got those weird "session expired" errors after hitting the back button, you've ran into the pitfalls of doing it this way.
rileymat2 1y ago
As far as preventing editing, but not reading, JWTs are very common.
briHass 1y ago
Anything on the ASP.NET stack has it in forms auth tickets and role cookies. You could store additional data in the forms auth one, and it auto-rotates the encryption at half the session length. One of the best authentication libraries at the time.
- mubou 1y ago
  ASP.NET is so underrated. It's by far the most comprehensive and adaptable web framework I've ever encountered.
  - solardev 1y ago
    Microsoft's developer experience is often world class. If they hadn't burned so much goodwill in the 90s and 2000s through embrace, extend, extinguish, they might have won (or at least stayed relevant) through the Web wars. It's still hard to trust them today, for me at least.
    - mubou 1y ago
      The fact that we're both being downvoted without a reply/explanation is a testament to that, it seems :( I can't imagine anyone who's actually used it responding that way.
dudeinjapan 1y ago
Many web frameworks like Rails allow you to easily fully encrypt (make unreadable to browser) or sign (make readable but not editable) with a server-side key. Some pen testers will report unsigned or unencrypted cookies so I imagine its quite common.
3np 1y ago
Storing JWTs as cookies is not that rare in practice.
Fire-Dragon-DoL 1y ago
Rails encrypts them too, or sign them, one of the two. Either way, you cannot tamper them
franga2000 1y ago
They used to be the norm in Django, Flask, RoR and ASP.NET, which made up the majority of the non-PHP web. These days database queries are cheap enough that most new sites just use session tokens, but that's also not something you can modify (well, besides transplanting it from a different session).

creatonez 1y ago

> Of all the CRUD operations, users can only realiably delete the cookie. I mean, one other operation I can think of is swapping a cookie out for a different one, so you can have two separate sessions managed independently... Which is essentially what Firefox's container tabs are.