11 ms·

If you have an API, you can program your web client like an API client, using bearer tokens for authentication (put them in local storage). It's probably bette

If you have an API, you can program your web client like an API client, using bearer tokens for authentication (put them in local storage). It's probably better than cookies.

beokop 8y ago
This sounds an awful lot like JWT.
- cbo100 8y ago
  In what way? You simply get a bearer token (non JWT) onto the client and use that from local storage instead of a cookie. Your JavaScript code then makes api calls using the same bearer pathway as other api clients. The token can still expire, be revoked, etc. it just prevents you having to handle cookie auth on your api.
  - geezerjay 8y ago
    You've just described the JWT workflow.
    - cbo100 8y ago
      Which is fine to use the same logic, as it’s a robust, easy to understand system. but if you aren’t using JWT then you aren’t using JWT. The parent comment saying “that sounds like JWT” is implying it’s just as bad or has the same shortfalls as using JWT.
      - lmm 8y ago
        The big objection to JWT is that it's a bearer token with no revocation support. If you're going to implement a bearer token with no revocation support, or a custom revocation implementation, anyway, then the criticisms of JWT apply just as much to the system you're building and you might as well just use JWT.
        beokop 8y ago
        Also, people make a big stink when authentication cookies aren’t marked as HTTPONLY. Storing tokens in localstorage (even sessionstorage) is just as bad but for some reason more accepted.
        metafunctor 8y ago
        Stealing tokens from localstorage or cookies means the attacker can run code in the user's security context. Why would they limit themselves to stealing tokens? Using them outside of the browser would be stupid, anyway, as it would risk tripping reauthentication, IPS, or whatever. HttpOnly is a joke, and people should stop claiming it helps with XSS. It does not help. It's security benefit is at most neutral. In fact, people often seem to think that it prevents XSS, and get lulled into a false sense of security. For that reason, HttpOnly seems to be worse than neutral.
        beokop 8y ago
        Persistent access via an authentication token is a hell of a lot more reliable than relying on the user not navigating from/refreshing a specific page where XSS is present.
        geezerjay 8y ago
        > The big objection to JWT is that it's a bearer token with no revocation support. That statement is not true. JWT do support revocation. In short, servers are free to reject any token, which triggers a token refresh on the client-side. Token revocation is even an intrinsic aspect of JWT as they suport issue and expiry timestamps, along with a nonce to avoid replay attacks. It seems some users have an axe to grind regarding the idea of having to keep track of some tokens that were poorly designed (i.e., absurdly long expiry dates without a nonce) but the solution quite obviously is to not misuse the technology. In the very least, if a developer feels compelled to use a broken bearer token scheme that does not expire tokens based on issue date then quite obviously he needs to keep a scratchpad database of blacklisted tokens to compensate for that design mistake.
    - pritambaral 8y ago
      No, they've described a Bearer Token workflow. JWT is a specific method that also (most times) uses Bearer tokens, but it wasn't the first, nor does it have a monopoly on Bearer tokens. I remember building a service when I was experimenting with web development that used randomly generated tokens in a custom HTTP header, and that is closer to Bearer Token (the standard) than Bearer Token is to JWT.
      - geezerjay 8y ago
        You're trying to be disingenuously pedantic. It's irrelevant if the workflow is specific to JWT or is shared by other bearer token schemes. The point is that JWT, which is a bearer token scheme, follows that workflow, thus it makes no sense to present that workflow as an alternative to the JWT workflow, as it's precisely the same.
        pritambaral 8y ago
        > ... as it's precisely the same. If you believe JWT is "precisely" the same as mere presentation of a token, then you're woefully ignorant of JWT. > ... it makes no sense to present that workflow as an alternative to the JWT workflow ... But that's not what happened, is it? In fact, it's the opposite. As I read it, [1] suggests a bearer token workflow, to which [2] replies that the suggestion is "an awful lot like JWT", whereupon [3] clarifies that the original suggestion is just a normal bearer token scheme, which, I claim, shares nothing with "JWT" except the "T". > ... JWT, which is a bearer token scheme ... The "T" in "JWT" is the least interesting bit of JWT, and merely a necessity. > It's irrelevant if the workflow is specific to JWT or is shared by other bearer token schemes When not talking about any specific bearer token scheme, it is absolutely relevant. Only the generic point was under discussion, until JWT was introduced. JWT is not just another bearer token scheme. It comes with its own additional obligations, restrictions, and extra steps, not to mention the purpose-defeating pitfalls. ---- [1]: https://news.ycombinator.com/item?id=18768173 https://news.ycombinator.com/item?id=18768173 [2]: https://news.ycombinator.com/item?id=18768212 https://news.ycombinator.com/item?id=18768212 [3]: https://news.ycombinator.com/item?id=18768242 https://news.ycombinator.com/item?id=18768242
moltar 8y ago
How is that better than a cookie though? Cookies already provide automatic storage and expiry mechanism. Bonus feature is that they are not accessible by JS code at all, if set httponly flag.
- metafunctor 8y ago
  Browsers automatically attach cookies to HTTP requests, opening the door to attacks like CSRF. The security impact of automatic client-side expiry is tiny, since token expiration must be done server-side anyway. The HttpOnly flag as an XSS mitigation is almost useless; competent attackers will simply run their code from the victim's browser and session. To protect against XSS, HttpOnly doesn't really help you at all. You should be setting a CSP that prevents inline and 3rd party scripts by default, and whitelist what you must. Overall, cookies may seem like they have a lot of security features, but in reality they are just patches over poor original design. IMHO, using local storage is probably better, because there's less room to get it wrong.
  - jakelazaroff 8y ago
    If you use cookies as a storage mechanism and ignore the cookie header on your backend, you close the door to CSRF attacks. Here's one glaring problem with local storage: literally any script on your page can access it (for example, vendor scripts). Cookies can only be accessed by scripts from the same domain from which they're created.
    - metafunctor 8y ago
      That's true, but if you run untrusted scripts on your site it's pretty much game over, anyway. Why should those scripts limit themselves to stealing tokens when they can send authenticated requests from the browser? To put it another way, why would you care about knowing the root password when you have a way to run a root shell at will?
      - jakelazaroff 8y ago
BlackMonday 8y ago
> It's probably better than cookies. Why do you think so? I would guess it's a tradeoff about what you think is more likely to happen. XSS or CSRF. Local storage (and session storage) is vulnerable to XSS. Use a strict content security policy and escape (htmlspecialchars in php and similar functions in other languages) output to combat that. Cookies are vulnerable to CSRF but can't be read from JS if they are http only (no XSS). To combat CSRF most frameworks already have built-in csrf token support. In case of a API use a double submit cookie. Frameworks like AngularJs/Angular support that out of the box. Also use the secure flag SameSite and __Host prefix [0][1] [0] https://www.youtube.com/watch?v=2uvrGQEy8i4 https://www.youtube.com/watch?v=2uvrGQEy8i4 [1] the slides from the video: https://www.owasp.org/images/3/32/David_Johansson-Double_Defeat_of_Double-Submit_Cookie.pdf https://www.owasp.org/images/3/32/David_Johansson-Double_Def...
- metafunctor 8y ago
  If you mean that HttpOnly for cookies protects against XSS, you are mistaken. The attacker will simply generate requests to the secure endpoints rather than steal the token and use it from somewhere else. HttpOnly does not really protect you against XSS at all.
  - BlackMonday 8y ago
    With "no XSS" I meant a XSS exploit doesn't allow access to the data stored in the cookie. I didn't mean it would protect against XSS. Poor/lazy wording on my part, sorry. It's true that a attacker simply can generate requests from the XSS'ed browser, my understanding was that the session/token is more valuable to an attacker then only an XSS exploit. However it seems that someone in the past had the same understanding as me and tptacek disagreed [0]. Oh well. Also reading the linked article [1] (are you the author since you use the same wording?) and it's linked articles it seems both cookies and webstorage are not ideal solutions, but local storage might be preferable since CSRF is not a problem, so one thing less to worry about. [0] https://news.ycombinator.com/item?id=11898525 https://news.ycombinator.com/item?id=11898525 [1] https://portswigger.net/blog/web-storage-the-lesser-evil-for-session-tokens https://portswigger.net/blog/web-storage-the-lesser-evil-for...

If you have an API, you can program your web client like an API client, using bearer tokens for authentication (put them in local storage). It's probably better than cookies.

beokop 8y ago

This sounds an awful lot like JWT.

cbo100 8y ago
In what way? You simply get a bearer token (non JWT) onto the client and use that from local storage instead of a cookie. Your JavaScript code then makes api calls using the same bearer pathway as other api clients. The token can still expire, be revoked, etc. it just prevents you having to handle cookie auth on your api.
- geezerjay 8y ago
  You've just described the JWT workflow.
  - cbo100 8y ago
    Which is fine to use the same logic, as it’s a robust, easy to understand system. but if you aren’t using JWT then you aren’t using JWT. The parent comment saying “that sounds like JWT” is implying it’s just as bad or has the same shortfalls as using JWT.
    - lmm 8y ago
      The big objection to JWT is that it's a bearer token with no revocation support. If you're going to implement a bearer token with no revocation support, or a custom revocation implementation, anyway, then the criticisms of JWT apply just as much to the system you're building and you might as well just use JWT.
      - beokop 8y ago
        Also, people make a big stink when authentication cookies aren’t marked as HTTPONLY. Storing tokens in localstorage (even sessionstorage) is just as bad but for some reason more accepted.
        metafunctor 8y ago
        Stealing tokens from localstorage or cookies means the attacker can run code in the user's security context. Why would they limit themselves to stealing tokens? Using them outside of the browser would be stupid, anyway, as it would risk tripping reauthentication, IPS, or whatever. HttpOnly is a joke, and people should stop claiming it helps with XSS. It does not help. It's security benefit is at most neutral. In fact, people often seem to think that it prevents XSS, and get lulled into a false sense of security. For that reason, HttpOnly seems to be worse than neutral.
        beokop 8y ago
        Persistent access via an authentication token is a hell of a lot more reliable than relying on the user not navigating from/refreshing a specific page where XSS is present.
      - geezerjay 8y ago
        > The big objection to JWT is that it's a bearer token with no revocation support. That statement is not true. JWT do support revocation. In short, servers are free to reject any token, which triggers a token refresh on the client-side. Token revocation is even an intrinsic aspect of JWT as they suport issue and expiry timestamps, along with a nonce to avoid replay attacks. It seems some users have an axe to grind regarding the idea of having to keep track of some tokens that were poorly designed (i.e., absurdly long expiry dates without a nonce) but the solution quite obviously is to not misuse the technology. In the very least, if a developer feels compelled to use a broken bearer token scheme that does not expire tokens based on issue date then quite obviously he needs to keep a scratchpad database of blacklisted tokens to compensate for that design mistake.
  - pritambaral 8y ago
    No, they've described a Bearer Token workflow. JWT is a specific method that also (most times) uses Bearer tokens, but it wasn't the first, nor does it have a monopoly on Bearer tokens. I remember building a service when I was experimenting with web development that used randomly generated tokens in a custom HTTP header, and that is closer to Bearer Token (the standard) than Bearer Token is to JWT.
    - geezerjay 8y ago
      You're trying to be disingenuously pedantic. It's irrelevant if the workflow is specific to JWT or is shared by other bearer token schemes. The point is that JWT, which is a bearer token scheme, follows that workflow, thus it makes no sense to present that workflow as an alternative to the JWT workflow, as it's precisely the same.
      - pritambaral 8y ago
        > ... as it's precisely the same. If you believe JWT is "precisely" the same as mere presentation of a token, then you're woefully ignorant of JWT. > ... it makes no sense to present that workflow as an alternative to the JWT workflow ... But that's not what happened, is it? In fact, it's the opposite. As I read it, [1] suggests a bearer token workflow, to which [2] replies that the suggestion is "an awful lot like JWT", whereupon [3] clarifies that the original suggestion is just a normal bearer token scheme, which, I claim, shares nothing with "JWT" except the "T". > ... JWT, which is a bearer token scheme ... The "T" in "JWT" is the least interesting bit of JWT, and merely a necessity. > It's irrelevant if the workflow is specific to JWT or is shared by other bearer token schemes When not talking about any specific bearer token scheme, it is absolutely relevant. Only the generic point was under discussion, until JWT was introduced. JWT is not just another bearer token scheme. It comes with its own additional obligations, restrictions, and extra steps, not to mention the purpose-defeating pitfalls. ---- [1]: https://news.ycombinator.com/item?id=18768173 https://news.ycombinator.com/item?id=18768173 [2]: https://news.ycombinator.com/item?id=18768212 https://news.ycombinator.com/item?id=18768212 [3]: https://news.ycombinator.com/item?id=18768242 https://news.ycombinator.com/item?id=18768242

moltar 8y ago

How is that better than a cookie though? Cookies already provide automatic storage and expiry mechanism. Bonus feature is that they are not accessible by JS code at all, if set httponly flag.

metafunctor 8y ago
Browsers automatically attach cookies to HTTP requests, opening the door to attacks like CSRF. The security impact of automatic client-side expiry is tiny, since token expiration must be done server-side anyway. The HttpOnly flag as an XSS mitigation is almost useless; competent attackers will simply run their code from the victim's browser and session. To protect against XSS, HttpOnly doesn't really help you at all. You should be setting a CSP that prevents inline and 3rd party scripts by default, and whitelist what you must. Overall, cookies may seem like they have a lot of security features, but in reality they are just patches over poor original design. IMHO, using local storage is probably better, because there's less room to get it wrong.
- jakelazaroff 8y ago
  If you use cookies as a storage mechanism and ignore the cookie header on your backend, you close the door to CSRF attacks. Here's one glaring problem with local storage: literally any script on your page can access it (for example, vendor scripts). Cookies can only be accessed by scripts from the same domain from which they're created.
  - metafunctor 8y ago
    That's true, but if you run untrusted scripts on your site it's pretty much game over, anyway. Why should those scripts limit themselves to stealing tokens when they can send authenticated requests from the browser? To put it another way, why would you care about knowing the root password when you have a way to run a root shell at will?
    - jakelazaroff 8y ago

BlackMonday 8y ago

> It's probably better than cookies. Why do you think so? I would guess it's a tradeoff about what you think is more likely to happen. XSS or CSRF. Local storage (and session storage) is vulnerable to XSS. Use a strict content security policy and escape (htmlspecialchars in php and similar functions in other languages) output to combat that. Cookies are vulnerable to CSRF but can't be read from JS if they are http only (no XSS). To combat CSRF most frameworks already have built-in csrf token support. In case of a API use a double submit cookie. Frameworks like AngularJs/Angular support that out of the box. Also use the secure flag SameSite and __Host prefix [0][1] [0] https://www.youtube.com/watch?v=2uvrGQEy8i4 https://www.youtube.com/watch?v=2uvrGQEy8i4 [1] the slides from the video: https://www.owasp.org/images/3/32/David_Johansson-Double_Defeat_of_Double-Submit_Cookie.pdf https://www.owasp.org/images/3/32/David_Johansson-Double_Def...

metafunctor 8y ago
If you mean that HttpOnly for cookies protects against XSS, you are mistaken. The attacker will simply generate requests to the secure endpoints rather than steal the token and use it from somewhere else. HttpOnly does not really protect you against XSS at all.
- BlackMonday 8y ago
  With "no XSS" I meant a XSS exploit doesn't allow access to the data stored in the cookie. I didn't mean it would protect against XSS. Poor/lazy wording on my part, sorry. It's true that a attacker simply can generate requests from the XSS'ed browser, my understanding was that the session/token is more valuable to an attacker then only an XSS exploit. However it seems that someone in the past had the same understanding as me and tptacek disagreed [0]. Oh well. Also reading the linked article [1] (are you the author since you use the same wording?) and it's linked articles it seems both cookies and webstorage are not ideal solutions, but local storage might be preferable since CSRF is not a problem, so one thing less to worry about. [0] https://news.ycombinator.com/item?id=11898525 https://news.ycombinator.com/item?id=11898525 [1] https://portswigger.net/blog/web-storage-the-lesser-evil-for-session-tokens https://portswigger.net/blog/web-storage-the-lesser-evil-for...