Caching JWS tokens to improve performance about fast-jwt

[ShogunPanda]

I'll go for a SHA256 hashing of cache keys. This should fix security issues.

@panva Does it sound reasonable?

[ShogunPanda]

This is my fault here.
I'm about to send an additional section in the README which explain how caching works:

fast-jwt supports caching of signed, decoded and verified tokens.

The cache layer, powered by [mnemonist](https://www.npmjs.com/package/mnemonist), is a LRU cache which dimension is controlled by the user, as described in the option list.

Signed tokens are cached only if the `iat` claim (which being time sensitive would be make the caching not meaningful) is not present inside the payload.

Decoded and verified tokens are always cached. If the decoding fails once, the error is cached as well and the operation is not retried.

For verified tokens, caching considers the time sensitive claims of the token (`iat`, `nbf` and `exp`) and make sure the verification is retried after a token becomes valid or after a token becomes expired.

Performances improvements varies by uses cases and by the type of the operation performed.

In our tests, performances improved by 10 times in case of decoding to 10000 times in the case of RS256 signing.

That said, do you still think we have a security issue here? If that's the case, I think I would go for option 2.

[dgonzalez]

Nope. I think that is spot on.

[panva]

I'm strongly objecting against storing the raw token values in memory. With all the recent attacks on memory data, evictions etc it's a vector you're opening up without the developer knowing. An attacker would e.g. only have to use new Buffer(n) construct to eventually hit these evicted memory blocks...

As a matter of fact, i don't believe this cache belongs in the core module, if anything offer it as a tagalong package that can wrap around this one with detailed enough information on what is stored, how and for how long.

[dgonzalez]

That is the exact same problem as other types of token auth (when token is no JWT, just a random string). It would be subsceptible of memory swapping attack.

[dgonzalez]

You can always store the hash of the token and the claims. That is not reversible.

[mcollina]

Storing the hash would be a fantastic way to make the verify operation as fast as a single hash function. This would generate a good improvement for RS* algorithms.

[dgonzalez]

Yeah... and also hash is ok to be paged. Another option would be protect the memory the same way that hashicorp vault does but not sure how practical that is.

[panva]

@ShogunPanda the hashing algorithm should be on the same level as the actual underlying hashing algorithm used in the JWA algorithm. For the currently registered (or in case of ES256K, WGLC passed) JWS algorithms it goes like this.

JWS algorithm	used hash algorithm
HS256, RS256, PS256, ES256, ES256K	sha256(message)
HS384, RS384, PS384, ES384	sha384(message)
HS512, RS512, PS512, ES512	sha512(message)
EdDSA (Ed25519 curve)	sha512(message)
EdDSA (Ed448 curve)	shake256(message, 114)

[ShogunPanda]

@panva You're right, but I don't want to complicate the implementation too much. As a tradeoff, I'll go with sha512, since performances are similar.

[panva]

@ShogunPanda how is that complicated? You just pass a different argument value to crypto.createHash ...

[ShogunPanda]

Not code wise, but performance wise: it is that simple once you know which algorithm to use. Which, when getting the cache back, means decoding the token. That is what I'd like to avoid.

[panva]

You'd only have to decode the header, not the potentially sizeable payload. I don't subscribe to compromises in the doing things "right" department just to squeeze a few more cycles out of the process ;)

[ShogunPanda]

Ok, no problem. I've implemented this feature and will commit ASAP.

[ShogunPanda]

Fixed in #12