Understanding PASETO: A Modern and Secure Alternative to JWT

In the world of web security, securely transmitting information between parties is very important. JSON Web Tokens (JWT) — which we explored in last blog Understanding JWT: The Key to Secure and Stateless Authentication— have been widely used for this purpose. However, JWT has several vulnerabilities that can be exploited if not implemented correctly. PASETO (Platform-Agnostic Security Tokens) is a modern alternative designed to address these shortcomings and provide a more secure and developer-friendly solution. In this blog, we’ll explore what PASETO is, why it’s a better choice by exploring the vulnerability of JWT, and how it works.

What is PASETO?

PASETO stands for Platform-Agnostic Security Tokens. It is a secure token format designed to be easy to use while avoiding many of the pitfalls associated with JWT. PASETO aims to provide a safer and simpler way to handle tokens, enforcing robust cryptographic practices and reducing the risk of common vulnerabilities. Let’s take a deeper look into the structure of PESTO.

Structure of PASETO

PASETO tokens are designed to be simple and secure, with a clear and consistent format. Each token consists of three main parts and one optional part: the version, the purpose, and the payload, Footer (Optional). So ultimately it becomes {version}.{purpose}.{payload}.{footer — optional}

Let’s break down each of these components.

1. Version

The version indicates the specific version of the PASETO protocol being used. As of now, there are four versions. The version is important because it dictates the algorithms and practices used for encryption and signing.

2. Purpose

The purpose defines what kind of token it is and how it should be handled. There are two primary purposes:

• Local (encrypted): Uses symmetric encryption to keep the contents of the token confidential. The purpose string for local tokens is local.
• Public (signed): Uses asymmetric encryption (public/private key pair) to ensure the token’s authenticity. The purpose string for public tokens is public.

3. Payload

The payload is the core part of the token, containing the actual data being transmitted. Depending on the purpose, the payload is either encrypted (local) or signed (public).

Let’s break down a hypothetical PASETO token to understand its components:

v2.local.EyJpZCI6ICIxMjM0NTYifQ==.footer

• Version (v2): Indicates that this is a version 2 PASETO token.
• Purpose (local): Indicates that this is a local token (symmetric encryption).
• Payload (EyJpZCI6ICIxMjM0NTYifQ==): This base64url-encoded string represents the encrypted JSON payload.
• When decoded, it could represent a JSON object like {"id": "123456"}.
• Footer (footer): Optional metadata included in the token.

A Brief Note on Cryptographic Algorithms

PASETO v2 uses the following algorithms, ensuring strong and modern cryptographic standards: Local Tokens: AES-256-CTR for encryption and HMAC-SHA-384 for authentication. Public Tokens: Ed25519 for digital signatures.

Vulnerability in JWT

Now that we know how PASETO is structured, you might argue that what is the difference between JWT and PASETO as both of them work very similarly. Let’s take a look at the vulnerabilities of JWT to understand PASETO better.

1. Algorithm Confusion Vulnerability

JWT allows the use of multiple algorithms for signing tokens (e.g., HS256, RS256). This flexibility can lead to an “algorithm confusion” attack where an attacker modifies the token header to use an algorithm they can control (like none or switching from RS256 to HS256). If the server accepts the modified token, the attacker can craft their own token without a signature.

Example:

{
  "alg": "HS256",
  "typ": "JWT"
}

to

{
  "alg": "none",
  "typ": "JWT"
}

PASETO Solution: PASETO eliminates this vulnerability by not allowing algorithm selection in the token itself. PASETO has predefined algorithms for each token version, so there is no ambiguity or possibility of an algorithm confusion attack.

2. Insecure Default Configuration

JWT libraries often come with insecure defaults, such as accepting tokens signed with weak algorithms or not validating signatures properly. Developers might not always change these defaults, leading to vulnerabilities.

Example: A library might accept a JWT token signed with HS256 by default, which could be susceptible to brute-force attacks if a weak key is used.

PASETO Solution: PASETO has secure-by-default configurations. It defines strong, modern cryptographic algorithms that are used consistently, reducing the likelihood of insecure implementations.

3. Token Tampering

If a JWT is not properly validated, an attacker can tamper with the token payload. This can happen if the signature verification step is skipped or improperly handled.

Example: An attacker could modify the payload of a JWT to escalate privileges or impersonate another user if the server does not correctly verify the token signature.

PASETO Solution: PASETO’s design enforces strict cryptographic standards and best practices, making it harder to tamper with the token. The predefined algorithms and clear separation between public and private tokens ensure robust security.

4. Lack of Built-in Claims Validation

JWT relies on developers to manually validate claims like exp (expiration), nbf (not before), and iss (issuer). This can lead to mistakes or omissions in validation logic.

Example: A developer might forget to check the exp claim, allowing an expired token to be accepted.

PASETO Solution: PASETO encourages best practices in claims validation by providing clear guidelines and helper functions for common validation tasks, reducing the likelihood of developer errors.

5. Complex and Error-Prone Libraries

JWT libraries can be complex and have many configuration options, which can lead to misconfigurations and vulnerabilities.

Example: A developer might incorrectly configure a JWT library, leading to vulnerabilities like accepting unsigned tokens or using weak keys.

PASETO Solution: PASETO libraries are designed to be simpler and less error-prone. They have fewer configuration options and enforce secure defaults, making it easier for developers to use them correctly.

How PASETO Works

PASETO tokens come in two versions: local and public. Local tokens are symmetrically encrypted and authenticated, while public tokens are asymmetrically signed.

Local Tokens (Symmetric Encryption)

Local tokens are useful when you want to keep the contents of the token confidential and ensure they haven’t been tampered with. They use a shared secret for both encryption and decryption.

Example: Creating a Local Token:

import pyseto
from pyseto import Key
key = Key.new(version=4, purpose="local", key=b"our-secret")
token = pyseto.encode(
    key, '{"data": "this is a signed message", "exp": "2024-07-13T00:00:00+00:00"}'
)

Decrypting a Local Token:

import pyseto
from pyseto import Key
key = Key.new(version=4, purpose="local", key=b"our-secret")
decoded = pyseto.decode(key, token)

Public Tokens (Asymmetric Signing)

Public tokens are useful when you need to verify the authenticity of the token without keeping its contents confidential. They use a public/private key pair for signing and verification.

Creating a Public Token:

import pyseto
from pyseto import Key
secret_key_pem = b"-----BEGIN PRIVATE KEY-----\nMC4CAQAwBQYDK2VwBCIEILTL+0PfTOIQcn2VPkpxMwf6Gbt9n4UEFDjZ4RuUKjd0\n-----END PRIVATE KEY-----"
public_key_pem = b"-----BEGIN PUBLIC KEY-----\nMCowBQYDK2VwAyEAHrnbu7wEfAP9cGBOAHHwmH4Wsot1ciXBHwBBXQ4gsaI=\n-----END PUBLIC KEY-----"
secret_key = Key.new(version=4, purpose="public", key=secret_key_pem)
token = pyseto.encode(
    secret_key,
    '{"data": "this is a signed message", "exp": "2024-07-13T00:00:00+00:00"}',
)

Decoding the contents:

import pyseto
from pyseto import Key
public_key_pem = b"-----BEGIN PUBLIC KEY-----\nMCowBQYDK2VwAyEAHrnbu7wEfAP9cGBOAHHwmH4Wsot1ciXBHwBBXQ4gsaI=\n-----END PUBLIC KEY-----"
public_key = Key.new(4, "public", public_key_pem)
decoded = pyseto.decode(public_key, token)

Conclusion

PASETO provides a robust and secure alternative to JWT by eliminating algorithm confusion, enforcing secure-by-default configurations, and simplifying the implementation process. By choosing PASETO, developers can avoid many of the common pitfalls associated with JWT and ensure a higher level of security for their applications.

If you’re looking to improve the security of your token-based authentication, consider giving PASETO a try. Its design and features make it a compelling choice for modern applications requiring secure tokenization.