5 ms·

1) Huh. Weird it exists at all then. 2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn

by iamwil 9y ago

1) Huh. Weird it exists at all then. 2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn't need to look up a valid token upon every request--which scales better. In my case, the API endpoint is for something that doesn't (and won't) get a lot of traffic, so I can probably get away with a 256-bit random token over TLS? Since it's over TLS, there probably aren't MITM attacks to sniff the token and replaying it--so it's probably ok? Are there other considerations I'm not aware of?

lvh 9y ago
It's not always a foregone conclusion that it scales better. I've seen people argue that when using ECDSA verification that's 4x longer than an in-DC RTT. Usually: DB kv lookups aren't even close to the most expensive thing your app does. Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0]. [0]: https://github.com/paragonie/paseto https://github.com/paragonie/paseto
- iamwil 9y ago
  By secretbox, I assume you mean NaCl's secretbox. Cool, thanks for the tips, and helping make the web a more cryptographically secure place.
- ketralnis 9y ago
  > Generally: don't do encrypted tokens Can you point to a RTFM on why not? I'm sure it's a big list of reasons but where can I read about the biggest one?
  - lvh 9y ago
    Because they cause more problems than they solve. A lot of the implementations _aren't even faster_, but the laundry list of security bugs they have caused is very real. Suddenly you get to worry about irrevocable tokens in order to solve scaling problems you don't have. A good intro is: http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.png http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.pn...
    - iamwil 9y ago
      from: http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...
jwilk 9y ago
1) Adam Langley explains why SHA-3 exists and why it shouldn't be used: https://www.imperialviolet.org/2017/05/31/skipsha3.html https://www.imperialviolet.org/2017/05/31/skipsha3.html

by iamwil 9y ago

lvh 9y ago

It's not always a foregone conclusion that it scales better. I've seen people argue that when using ECDSA verification that's 4x longer than an in-DC RTT. Usually: DB kv lookups aren't even close to the most expensive thing your app does. Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0]. [0]: https://github.com/paragonie/paseto https://github.com/paragonie/paseto

iamwil 9y ago
By secretbox, I assume you mean NaCl's secretbox. Cool, thanks for the tips, and helping make the web a more cryptographically secure place.
ketralnis 9y ago
> Generally: don't do encrypted tokens Can you point to a RTFM on why not? I'm sure it's a big list of reasons but where can I read about the biggest one?
- lvh 9y ago
  Because they cause more problems than they solve. A lot of the implementations _aren't even faster_, but the laundry list of security bugs they have caused is very real. Suddenly you get to worry about irrevocable tokens in order to solve scaling problems you don't have. A good intro is: http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.png http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.pn...
  - iamwil 9y ago
    from: http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

jwilk 9y ago

1) Adam Langley explains why SHA-3 exists and why it shouldn't be used: https://www.imperialviolet.org/2017/05/31/skipsha3.html https://www.imperialviolet.org/2017/05/31/skipsha3.html