13 ms·

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be ma

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over port 80 revoke that token). - If you go with OpenID/Oauth for client sign-ins then require https callbacks and provide scoped permissions. - Don't use JWT [3]. Don't use CORS [4]. Again these are broad strokes - if you gave more information you'd get a better response. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se... [2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St... [3]: https://en.wikipedia.org/wiki/JSON_Web_Token https://en.wikipedia.org/wiki/JSON_Web_Token [4]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

atonse 8y ago
Isn't the argument against JWT mainly one against using it with weak algorithms, and not something inherent to JWT itself?
- throwawaymath 8y ago
  No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. Thus instead of using a turnkey solution you need to add an additional layer of state logic to your authentication code if you want to be able to revoke tokens. It is also correct that JWT 1) supports far more cryptography than is necessary; and 2) supports weak cryptography. You can do better than JWT for session management security and performance merely by generating pseudorandom tokens, associating them to sessions and performing lookups. More generally speaking: signed, stateless tokens are attractive for a variety of technical reasons. They have legitimate uses. But it's typically a poor security decision to choose them in lieu of revocation, for reasons which are mostly uncontroversial among those who work in security.
  - geezerjay 8y ago
    > No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. That's technically false. JWT features multiple systems of revocation, including the use of nonces. Token revocation also features prominently in JWT's basic workflow. The key aspect is that there is no turnkey implementation, and thus projects need to roll their own implementation, which is frowned upon some developers.
    - throwawaymath 8y ago
      By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. It naturally follows that no JWT implementation provides a turnkey solution for revocation, because it's not intended to. JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation system. But at that point you're back to square one and the architect working on this should consider why they're undoing the legitimate benefits JWT provides. Nonce based revocation is an active process. Timestamp expiry is not actually revocation, it's expiry. If your token is compromised prior to expiry, you're out of luck.
      - geezerjay 8y ago
        > By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. That's patently false. JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes. The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens. > JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. This sort of argument is ivory tower nitpicking stated disingenuously. JWT include issue and revocation timestamps, which already renders the workflow stateless. The only stateful aspect, which is silly nitpicking and technically irrelevant, is keeping track of nonces and arbitrarily revoked tokens, which require keeping a database to track revocations.
- deleted 8y ago
  [deleted]
vortegne 8y ago
Why not JWT?
- cjcampbell 8y ago
  An oversimplified version of the arguments against JWT for session management (as well as the JOSE specification for signing and encryption) ... 1. The specification has points of ambiguity that have led to a number of flawed implementations. 2. JWT is saddled with unnecessary complexity which also contributes to recurring implementation flaws. 3. JWT increases the complexity of session revocation in contrast to a simple, stateless session ID. The arguments and counter-arguments are a bit more involved, but be aware that by the time you account for the downsides, you may have negated the value you hoped to gain from stateless web tokens. If you can use a simple session id, use it. If you need JWT to support external authentication providers, use a short expiration and swap the (fully verified) token for a session id.
atonse 8y ago
Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours included)
- askmike 8y ago
  Wondering about the same thing.
- tinco 8y ago
  Some people have performance concerns with CORS is the main reason I believe. The overhead is an extra round trip.
  - atonse 8y ago
    I thought the concern was security. Anyway HTTP2 would hopefully address that (through header compression), and things like zero-RTT TLS and keep-alive further minimize the overhead of an additional request. Plus doesn't CORS only make preflight requests periodically, not for every request?
    - luhn 8y ago
      Preflights are cached, but because CORS is per-URL caching can be of limited value. If your API uses `/info` and `/edit`, a preflight request has to be made for both (assuming a preflight is necessary). If your application has dynamic URLs (e.g. `/widget/1`, `/widget/2`, etc.) the problem is exacerbated even further.
    - Ayesh 8y ago
      I wrote/research a lot about http/2, and even has a small tool for it (https://http2.pro https://http2.pro). Among many things you get from http/2, it cannot eliminate round trip time. Sure, you can keep a connection alive but that's possible with http 1.1 too. Header compression is HPACK. If the header changes even the slightest bit, it's not cached. Dynamic URLs and headers can easily bust HPACK compression.
- 8y ago
aeleos 8y ago
Isn't JWT also a type of bearer token? Could you please provide some more detailed arguments about why JWT shouldn't be used other than linking its wikipedia article?
- mcbits 8y ago
  JWT is fine if "revoke" isn't in your vocabulary for the service. If you do need to revoke tokens, JWT becomes a racey contraption that requires synchronizing and looking up state on every request, the avoidance of which was the main reason to use JWT in the first place.
  - kc10 8y ago
    It's a common practice to add expiry timestamp for such tokens so each token will expire after certain interval.
    - throwawaymath 8y ago
      That's dandy, but it's a solution which is neither standardized nor native to JWT. It's also a weak, passive form of revocation instead of a robust, active form. How do do you revoke a token prior to timestamp expiry? In 2018 it is fully possible to use authentication libraries which natively support granular control for things like revocation using strong, turnkey cryptography. I would argue most people who think they should be using stateless and signed sessions for e.g. performance are heavily discounting the revocation liability and neglecting to optimize their lookups sufficiently (such as by caching).
      - geezerjay 8y ago
        > That's dandy, but it's a solution which is neither standardized nor native to JWT. That statement is false. JWT were specifically designed to store a payload JSON object which among the many standardized fields include the token's expiry time, and JWT were specifically designed with a workflow which includes not only client-side token refreshing but also server-side token rejection that triggers client-side token refreshes. In fact, JWT token refreshes and token rejections feature in any basic intro tutorial to JWT, including the design principle that tokens should be discarded and refreshed by the client as soon as possible and also the use of nonces.
metafunctor 8y ago
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.
misiti3780 8y ago
correct me if i am wrong, but if your backend and front-end run on different ports and you are developing locally using chrome, you have to use CORS to make any non GET requests
- cosmosgenius 8y ago
  What we do is make the frontend server(eg ng serve) proxy request to backend during development.
Klathmon 8y ago
> if someone makes a request over port 80 revoke that token I really like this trick! Not only do you now have a log of "shady stuff" happening, but you've gotten rid of the now compromised tokens instantly!
- i_cant_speel 8y ago
  Can you elaborate on what this means? I'm not too familiar with authentication flows. Why would someone make a request over port 80? Why is that bad?
  - huntertwo 8y ago
    Requests sent to port 80 will (usually) be unencrypted HTTP traffic, hence revealing the secret token to anybody listening in between the client and the server. Someone may accidentally send an HTTP request either by typo or lack of knowledge.
  - rocqua 8y ago
    Im guessing a downgrade attack where a mitm convinces the client to use plaon http so they can read the plain text credential.
    - deleted 8y ago
      [deleted]
  - Klathmon 8y ago
    To kind of combine the others comments and add some more depth: HTTPS runs over port 443, and port 80 is normally for HTTP only. Most people setup their webservers to serve HTTPS over 443 and redirect port 80 to 443 so anyone that sends something to `http://example.com` http://example.com` automatically gets forwarded to `https://example.com` https://example.com` (and then the browser can tell them to ONLY use the HTTPS version from that point forward) This is a generally "acceptable" tradeoff between usability and security. But when you control the API and the client, you can know that you will never send credentials over HTTP, only HTTPS. So you should have nothing coming over port 80. Then, with a simple script, you could set it up so that it will accept everything on port 80, and if it includes a token of some kind from your app, it logs the request, then marks the token in your database as "expired" so it can no longer be used anywhere (even on port 443). There's a kind of attack sometimes called "SSLStrip" which can block all requests for someone to an HTTPS version of the site, and in many cases can trick the client into trying the HTTP version if the HTTPS fails. This kind of thing would not only stop that attack, but it would also log it and ensure that any tokens sent that way would be instantly expired, so that the attacker (who saw the tokens when the client tried to send them) can't use them. There are other reasons too. It will notify you of any developer-mistakes that are sending credentials over HTTP (it's a one letter difference, and despite the best efforts sometimes these kinds of things slip into a codebase as typos or a dev just not thinking), and it can help you tell "scanning" traffic from "normal" traffic (since nothing in your app will ever talk to port 80, so everything on port 80 is "bad" and can give you some clues into what attackers are trying on your network). And the best part is that it's easy! I could probably throw something together for our API servers that does this in a day or so start-to-finish. That's a REALLY good ratio between time spent and security benefit that you normally don't get!
tixocloud 8y ago
What’s the difference between a Bearer Token and JWT? I thought they were related?
- nine_k 8y ago
  JWT in particular uses cryptography to encode a timestamp and some other parameters. This way, you can check if it's valid by just decrypting it, without hitting a DB. Not all bearer tokens have this property.
- luhn 8y ago
  A bearer token is opaque. It could be a JWT, it could be something else, depending on the application.
- geezerjay 8y ago
  In essence, a JSON Web Token (JWT) is a bearer token. It's a particular implementation which has been specified and standardised.
- beckler 8y ago
  A bit of misinformation in this side thread. A JWT token is composed of three parts: a header, payload, and signature. The problem is that people can put sensitive info in the payload. None of it is encrypted, it's only signed with HMAC. Unless you're keeping track of the tokens, once a token is issued it's valid until it expires, due to it's stateless nature. You can use a JWT as a Bearer token, but since it's only base64 encoded, you can pull out that payload data. A truly opaque Bearer token will be meaningless to anything other than your server. Play with the debugger here to see what I'm talking about: https://jwt.io/ https://jwt.io/
xfitm3 8y ago
Where does Amazon’s sigv4 fall into play?
jammygit 8y ago
Does sameSite mean you don't need to worry about anti-csrf tokens, or does it just augment it?
- Ayesh 8y ago
  SameSite cookies can eliminate threats from cross domain requests. The strict mode is good enough to even block cross domain regular GET requests too. However, I wouldn't throw other anti-CSRF measures away because if the attacker can use a stored XSS vuln, they can still make their way to a CSRF as well. Besides that, not all browsers support SameSite flag yet.

atonse 8y ago

Isn't the argument against JWT mainly one against using it with weak algorithms, and not something inherent to JWT itself?

throwawaymath 8y ago
No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. Thus instead of using a turnkey solution you need to add an additional layer of state logic to your authentication code if you want to be able to revoke tokens. It is also correct that JWT 1) supports far more cryptography than is necessary; and 2) supports weak cryptography. You can do better than JWT for session management security and performance merely by generating pseudorandom tokens, associating them to sessions and performing lookups. More generally speaking: signed, stateless tokens are attractive for a variety of technical reasons. They have legitimate uses. But it's typically a poor security decision to choose them in lieu of revocation, for reasons which are mostly uncontroversial among those who work in security.
- geezerjay 8y ago
  > No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. That's technically false. JWT features multiple systems of revocation, including the use of nonces. Token revocation also features prominently in JWT's basic workflow. The key aspect is that there is no turnkey implementation, and thus projects need to roll their own implementation, which is frowned upon some developers.
  - throwawaymath 8y ago
    By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. It naturally follows that no JWT implementation provides a turnkey solution for revocation, because it's not intended to. JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation system. But at that point you're back to square one and the architect working on this should consider why they're undoing the legitimate benefits JWT provides. Nonce based revocation is an active process. Timestamp expiry is not actually revocation, it's expiry. If your token is compromised prior to expiry, you're out of luck.
    - geezerjay 8y ago
      > By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. That's patently false. JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes. The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens. > JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. This sort of argument is ivory tower nitpicking stated disingenuously. JWT include issue and revocation timestamps, which already renders the workflow stateless. The only stateful aspect, which is silly nitpicking and technically irrelevant, is keeping track of nonces and arbitrarily revoked tokens, which require keeping a database to track revocations.
deleted 8y ago
[deleted]

vortegne 8y ago

Why not JWT?

cjcampbell 8y ago
An oversimplified version of the arguments against JWT for session management (as well as the JOSE specification for signing and encryption) ... 1. The specification has points of ambiguity that have led to a number of flawed implementations. 2. JWT is saddled with unnecessary complexity which also contributes to recurring implementation flaws. 3. JWT increases the complexity of session revocation in contrast to a simple, stateless session ID. The arguments and counter-arguments are a bit more involved, but be aware that by the time you account for the downsides, you may have negated the value you hoped to gain from stateless web tokens. If you can use a simple session id, use it. If you need JWT to support external authentication providers, use a short expiration and swap the (fully verified) token for a session id.

atonse 8y ago

Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours included)

askmike 8y ago
Wondering about the same thing.
tinco 8y ago
Some people have performance concerns with CORS is the main reason I believe. The overhead is an extra round trip.
- atonse 8y ago
  I thought the concern was security. Anyway HTTP2 would hopefully address that (through header compression), and things like zero-RTT TLS and keep-alive further minimize the overhead of an additional request. Plus doesn't CORS only make preflight requests periodically, not for every request?
  - luhn 8y ago
    Preflights are cached, but because CORS is per-URL caching can be of limited value. If your API uses `/info` and `/edit`, a preflight request has to be made for both (assuming a preflight is necessary). If your application has dynamic URLs (e.g. `/widget/1`, `/widget/2`, etc.) the problem is exacerbated even further.
  - Ayesh 8y ago
    I wrote/research a lot about http/2, and even has a small tool for it (https://http2.pro https://http2.pro). Among many things you get from http/2, it cannot eliminate round trip time. Sure, you can keep a connection alive but that's possible with http 1.1 too. Header compression is HPACK. If the header changes even the slightest bit, it's not cached. Dynamic URLs and headers can easily bust HPACK compression.
8y ago

aeleos 8y ago

Isn't JWT also a type of bearer token? Could you please provide some more detailed arguments about why JWT shouldn't be used other than linking its wikipedia article?

mcbits 8y ago
JWT is fine if "revoke" isn't in your vocabulary for the service. If you do need to revoke tokens, JWT becomes a racey contraption that requires synchronizing and looking up state on every request, the avoidance of which was the main reason to use JWT in the first place.
- kc10 8y ago
  It's a common practice to add expiry timestamp for such tokens so each token will expire after certain interval.
  - throwawaymath 8y ago
    That's dandy, but it's a solution which is neither standardized nor native to JWT. It's also a weak, passive form of revocation instead of a robust, active form. How do do you revoke a token prior to timestamp expiry? In 2018 it is fully possible to use authentication libraries which natively support granular control for things like revocation using strong, turnkey cryptography. I would argue most people who think they should be using stateless and signed sessions for e.g. performance are heavily discounting the revocation liability and neglecting to optimize their lookups sufficiently (such as by caching).
    - geezerjay 8y ago
      > That's dandy, but it's a solution which is neither standardized nor native to JWT. That statement is false. JWT were specifically designed to store a payload JSON object which among the many standardized fields include the token's expiry time, and JWT were specifically designed with a workflow which includes not only client-side token refreshing but also server-side token rejection that triggers client-side token refreshes. In fact, JWT token refreshes and token rejections feature in any basic intro tutorial to JWT, including the design principle that tokens should be discarded and refreshed by the client as soon as possible and also the use of nonces.

metafunctor 8y ago

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.

misiti3780 8y ago

correct me if i am wrong, but if your backend and front-end run on different ports and you are developing locally using chrome, you have to use CORS to make any non GET requests

cosmosgenius 8y ago
What we do is make the frontend server(eg ng serve) proxy request to backend during development.

Klathmon 8y ago

> if someone makes a request over port 80 revoke that token I really like this trick! Not only do you now have a log of "shady stuff" happening, but you've gotten rid of the now compromised tokens instantly!

i_cant_speel 8y ago
Can you elaborate on what this means? I'm not too familiar with authentication flows. Why would someone make a request over port 80? Why is that bad?
- huntertwo 8y ago
  Requests sent to port 80 will (usually) be unencrypted HTTP traffic, hence revealing the secret token to anybody listening in between the client and the server. Someone may accidentally send an HTTP request either by typo or lack of knowledge.
- rocqua 8y ago
  Im guessing a downgrade attack where a mitm convinces the client to use plaon http so they can read the plain text credential.
  - deleted 8y ago
    [deleted]
- Klathmon 8y ago
  To kind of combine the others comments and add some more depth: HTTPS runs over port 443, and port 80 is normally for HTTP only. Most people setup their webservers to serve HTTPS over 443 and redirect port 80 to 443 so anyone that sends something to `http://example.com` http://example.com` automatically gets forwarded to `https://example.com` https://example.com` (and then the browser can tell them to ONLY use the HTTPS version from that point forward) This is a generally "acceptable" tradeoff between usability and security. But when you control the API and the client, you can know that you will never send credentials over HTTP, only HTTPS. So you should have nothing coming over port 80. Then, with a simple script, you could set it up so that it will accept everything on port 80, and if it includes a token of some kind from your app, it logs the request, then marks the token in your database as "expired" so it can no longer be used anywhere (even on port 443). There's a kind of attack sometimes called "SSLStrip" which can block all requests for someone to an HTTPS version of the site, and in many cases can trick the client into trying the HTTP version if the HTTPS fails. This kind of thing would not only stop that attack, but it would also log it and ensure that any tokens sent that way would be instantly expired, so that the attacker (who saw the tokens when the client tried to send them) can't use them. There are other reasons too. It will notify you of any developer-mistakes that are sending credentials over HTTP (it's a one letter difference, and despite the best efforts sometimes these kinds of things slip into a codebase as typos or a dev just not thinking), and it can help you tell "scanning" traffic from "normal" traffic (since nothing in your app will ever talk to port 80, so everything on port 80 is "bad" and can give you some clues into what attackers are trying on your network). And the best part is that it's easy! I could probably throw something together for our API servers that does this in a day or so start-to-finish. That's a REALLY good ratio between time spent and security benefit that you normally don't get!

tixocloud 8y ago

What’s the difference between a Bearer Token and JWT? I thought they were related?

nine_k 8y ago
JWT in particular uses cryptography to encode a timestamp and some other parameters. This way, you can check if it's valid by just decrypting it, without hitting a DB. Not all bearer tokens have this property.
luhn 8y ago
A bearer token is opaque. It could be a JWT, it could be something else, depending on the application.
geezerjay 8y ago
In essence, a JSON Web Token (JWT) is a bearer token. It's a particular implementation which has been specified and standardised.
beckler 8y ago
A bit of misinformation in this side thread. A JWT token is composed of three parts: a header, payload, and signature. The problem is that people can put sensitive info in the payload. None of it is encrypted, it's only signed with HMAC. Unless you're keeping track of the tokens, once a token is issued it's valid until it expires, due to it's stateless nature. You can use a JWT as a Bearer token, but since it's only base64 encoded, you can pull out that payload data. A truly opaque Bearer token will be meaningless to anything other than your server. Play with the debugger here to see what I'm talking about: https://jwt.io/ https://jwt.io/

xfitm3 8y ago

Where does Amazon’s sigv4 fall into play?

jammygit 8y ago

Does sameSite mean you don't need to worry about anti-csrf tokens, or does it just augment it?

Ayesh 8y ago
SameSite cookies can eliminate threats from cross domain requests. The strict mode is good enough to even block cross domain regular GET requests too. However, I wouldn't throw other anti-CSRF measures away because if the attacker can use a stored XSS vuln, they can still make their way to a CSRF as well. Besides that, not all browsers support SameSite flag yet.