4 ms·

1) Yes, use SHA512/256 (truncated SHA512). I don't think I'd default to SHA3 anywhere. 2) Are you entirely convinced you actually need client tokens? In partic

by lvh 9y ago

1) Yes, use SHA512/256 (truncated SHA512). I don't think I'd default to SHA3 anywhere. 2) Are you entirely convinced you actually need client tokens? In particular, can you get away with a 256-bit random token and store the session in a database? 3) Re: HMAC input malleability: yep, concat and HMAC is fine. Serializing JSON or whatever is also fine. You're usually providing the tag (that's what the output of HMAC is called) verbatim next to the message, so you generally don't care about e.g. canonical serialization.

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 lvh 9y ago

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