Use a better algorithm than UTF-8 to derive keys from string secrets.

Currently, when I use the following code to generate a JWT:

const jwt = require('jsonwebtoken');
const secret = "my secret";
const token = jwt.sign({ "foo": "bar" }, secret); 

The actual binary key used for signing is derived from the secret using a simple UTF-8 string-to-byte.

I am surprised that the default sign method of the package uses no key derivation mechanism (like PBKDF2) to generate the signing key from given the secret. PBKDF2 does not solve the secret length issue, but it does mitigate the fact that simple UTF-8 string-to-byte is a very poor algorithm for key derivation, given that UTF-8 is not a bijection to binary data, and given that passphrases are generally plain ASCII strings, which has even less entropy than the full UTF-8 character set…

I raised an issue on the jws github project, but it could also be something to consider at the jsonwebtoken package level, e.g. change method signature and prefer buffer input rather than string secrets (buffer input is more likely to be generated from a truly random base64 key using Buffer.from(keyAsBase64String, "base64")).

[panva]

We could certainly update the examples and documentation, keeping in mind it’s not always the developer who’s choosing the secret values, such as in cases of OAuth 2.0 client authentication assertions with a shared client_secret or an OIDC AS signing ID Tokens with HMAC based JWAs. In all these instances the one who generates the random secret uses sufficient entropy to generate a hex or base64/url string value which is then by said specifications used, e.g.

the octets of the UTF-8 representation of the client_secret are used as the key to validate the signature

Bottom line library can do more to educate in its README but still has to accept a string for its face value as the signing key.

I for one would love to see a proposal going to the appropriate IETF WG for extending the JWA alg support with HS based methods that use KDF to get their secrets rather than having each implementer “do its own thing”.

[panva]

Would you like to propose a change to the README.md file?