16 min
Bill Buchanan - A Bluffers Guide To JWTs ASecuritySite Podcast
-
- Technology
Related blog: https://medium.com/asecuritysite-when-bob-met-alice/tokens-jwt-and-google-tink-c6b915d387e8
And: https://billatnapier.medium.com/hmac-or-public-key-signing-of-jwts-64084aff10ef
Introduction
My Top 20 important things about JWTs:
JWT is a JSON Web Token and is pronounced “jot”. JSON objects support human-readable text and are used in many applications, such as with NoSQL databases. You should not trust a JWT unless it is cryptographically signed. For authorization, a captured JWT can be replayed and “played back” to provide a malicious entry or rights into a system. JWTs should never be trusted before their issue date and their not-before date and never trusted after their expiry. JWTs have been defined as an RFC standard with RFC7519. The format is URL friendly and is Base64URL encoded. A JWT token has three main parameters separated by a period (“.”), and which are the header, the payload and the signature. The header is typically not encrypted and defines the signature algorithm (“alg”) and the type (“typ”). The payload is typically not encrypted and uses a Base64 format. The payload can typically be seen by anyone who captures it. “ey” is a typical field starting part of a parameter in the header and body of a token as ‘{“‘ encoded in Base64 is “ey==”. You can tell if a token is not encrypted with an “ey” as the start of the header and body parameters. The registered claims of a token are iss (Issuer), sub (Subject), aud (Audience), iat (Issued At), exp (Expires), nbf (Not Before), and jti (JWT ID). The claim fields are not mandatory and just a starting point for defining claims. A claim is asserted about a subject, and where we have a claim name and a claim value in a JSON format. With an HMAC signature, the issuer and validator must share the same secret symmetric key. If you use HMAC to sign the tokens, a breached secret key will compromise the signing infrastructure. The two main public key signing methods are RSA and ECDSA. The time of a token is represented as the number of seconds from 1 January 1970 (UTC). Each day of a JWT token is represented by 86,400 seconds. An unsecured JWT does not have encryption or a signature. This is bad! it is represented in the header parameter with an “alg” of “none” and an empty string for the JWS Signature value. A JWT can be encrypted (but this is optional). For public key methods, we can use either RSA and AES, or we can use a wrapped key. And a debate I’ve had with many development teams:
What’s a token? So, what’s a token? Well, it is basically a way to encapsulate data in a well-defined format that has a signature from the issuer. For this, we either sign using HMAC (HMAC-256, HMAC-384 or HMAC-512), RSA signing or ECC signing. The HMAC method requires the use of a secret symmetric key, whilst RSA and ECC use public key encryption. The problem with HMAC is that if someone discovers the secret key, they could sign valid tokens. For enhanced security, we typically use public key encryption, where we sign with a private key and then validate with the public key.
In this case, we will use Google Tink to create JWTs (JSON Web Tokens) and which are signed with elliptic curve cryptography. For this, we will use either NIST P-256 (ES256), NIST P-384 (ES384) or NIST P512 (ES512) for the curves. Overall, we do not generally encrypt the payload in JWT, so it can typically be viewed if the token is captured.
JWT format A JWT token splits into three files: header, payload and signature (Figure 1).
Figure 1: JWT format The header parameter The header contains the formation required to interpret the rest of the token. Typical fields are “alg” and “kid”, and these represent the algorithm you use (such as “ES256”) and the ID, representively. The default type (“type”) will be “JWT”. Other possible fields include “jwk” (JSON Web key), “cty” (Content type), and “x5u” (X.509 U
Related blog: https://medium.com/asecuritysite-when-bob-met-alice/tokens-jwt-and-google-tink-c6b915d387e8
And: https://billatnapier.medium.com/hmac-or-public-key-signing-of-jwts-64084aff10ef
Introduction
My Top 20 important things about JWTs:
JWT is a JSON Web Token and is pronounced “jot”. JSON objects support human-readable text and are used in many applications, such as with NoSQL databases. You should not trust a JWT unless it is cryptographically signed. For authorization, a captured JWT can be replayed and “played back” to provide a malicious entry or rights into a system. JWTs should never be trusted before their issue date and their not-before date and never trusted after their expiry. JWTs have been defined as an RFC standard with RFC7519. The format is URL friendly and is Base64URL encoded. A JWT token has three main parameters separated by a period (“.”), and which are the header, the payload and the signature. The header is typically not encrypted and defines the signature algorithm (“alg”) and the type (“typ”). The payload is typically not encrypted and uses a Base64 format. The payload can typically be seen by anyone who captures it. “ey” is a typical field starting part of a parameter in the header and body of a token as ‘{“‘ encoded in Base64 is “ey==”. You can tell if a token is not encrypted with an “ey” as the start of the header and body parameters. The registered claims of a token are iss (Issuer), sub (Subject), aud (Audience), iat (Issued At), exp (Expires), nbf (Not Before), and jti (JWT ID). The claim fields are not mandatory and just a starting point for defining claims. A claim is asserted about a subject, and where we have a claim name and a claim value in a JSON format. With an HMAC signature, the issuer and validator must share the same secret symmetric key. If you use HMAC to sign the tokens, a breached secret key will compromise the signing infrastructure. The two main public key signing methods are RSA and ECDSA. The time of a token is represented as the number of seconds from 1 January 1970 (UTC). Each day of a JWT token is represented by 86,400 seconds. An unsecured JWT does not have encryption or a signature. This is bad! it is represented in the header parameter with an “alg” of “none” and an empty string for the JWS Signature value. A JWT can be encrypted (but this is optional). For public key methods, we can use either RSA and AES, or we can use a wrapped key. And a debate I’ve had with many development teams:
What’s a token? So, what’s a token? Well, it is basically a way to encapsulate data in a well-defined format that has a signature from the issuer. For this, we either sign using HMAC (HMAC-256, HMAC-384 or HMAC-512), RSA signing or ECC signing. The HMAC method requires the use of a secret symmetric key, whilst RSA and ECC use public key encryption. The problem with HMAC is that if someone discovers the secret key, they could sign valid tokens. For enhanced security, we typically use public key encryption, where we sign with a private key and then validate with the public key.
In this case, we will use Google Tink to create JWTs (JSON Web Tokens) and which are signed with elliptic curve cryptography. For this, we will use either NIST P-256 (ES256), NIST P-384 (ES384) or NIST P512 (ES512) for the curves. Overall, we do not generally encrypt the payload in JWT, so it can typically be viewed if the token is captured.
JWT format A JWT token splits into three files: header, payload and signature (Figure 1).
Figure 1: JWT format The header parameter The header contains the formation required to interpret the rest of the token. Typical fields are “alg” and “kid”, and these represent the algorithm you use (such as “ES256”) and the ID, representively. The default type (“type”) will be “JWT”. Other possible fields include “jwk” (JSON Web key), “cty” (Content type), and “x5u” (X.509 U
16 min