paseto-standard

paseto-spec

Security & Privacy2021–2026

paseto-standard / paseto-spec

paseto-spec

Specification for Platform Agnostic SEcurity TOkens (PASETO)

Security & Privacy Learning & Reference

Explore on GitHub Read Hacker News discussions

6Distinct people

6Mentions

0Explicit recommenders

293GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Specification for Platform Agnostic SEcurity TOkens (PASETO)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year6 dated mentions

Observed mentions: 2021-08-25 00:36:22 UTC to 2026-06-17 07:51:20 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	2	2
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	2	2
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1

What Hacker News says

6 sources

unscaled·Jun 17, 2026

JWT libraries had poor defaults because the spec was poorly designed. Of course JWT can be implemented securely. Even XMLDSig can be implemented securely. But if the spec is not designed with security and misuse-resistance as a tier 1 priority, you will get more issues. The fact that we didn't see the same sheer volume of issues with PASETO or macaroon libraries (admittedly, the later are far less numerous). I can find only one CVE for a PASETO library from 2020, and this is an issue that has nothing to do with the algorithm itself (JPaseto < 0.3.0 switched the order of two arguments in their hash function call, generating weaker hashes). The reason PASETO won't have the same issues as JWT is the design (especially with v3/v4). There is no alg=none, symmetric keys are fixed size (so no weak keys can be used) and algorithm confusion is pre

Read the rest

vented by an explicit implementation guide[1] that strongly mandates that keys for different algorithm version have different types, and verification functions MUST reject a key of the wrong type. Is JWT safe now? Maybe. A lot of issues have been fixed, but new issues keep coming all the time. We're not even halfway into this year and I can count at least the following serious 2026 CVEs: CVE-2026-28802, CVE-2026-29000, CVE-2026-1529, CVE-2026-22817/8, CVE-2026-34950, CVE-2026-23993, CVE-2026-32597, just to name a few. Most of them are the same classic alg=none, signature verification bypass and algorithm confusion issues. The issues is that new libraries are coming all the time and the vulnerability elimination process for existing libraries is just a random scattershot. If a security researcher has happened across a vulnerability in library X and reported it, it's solved. If nobody has found it yet: though luck. Unless you pick a library that has been officially audited for these issues, you don't really know if it's truly safe. If you use a PASETO library, it's probably not audited either, but the chance of it having these common types of issues (and other issues, like psychic signatures[2]) are close to nil. --- [1] https://github.com/paseto-standard/paseto-spec/blob/master/d... [2] https://www.securecodewarrior.com/article/psychic-signatures

In Stop Using JWTs

some_furry·Sep 30, 2025

> how are you going to get "adversarial attacks" with prompt injection Lots of ways his could happen. To name two: Third-party software dependencies, HTTP requests for documentation (if your agent queries the Internet for information). If you don't believe me, setup a MITM proxy to watch network requests and ask your AI agent to implement PASETO in your favorite programming language, and see if it queries https://github.com/paseto-standard/paseto-spec at all.

In Claude Code 2.0

RainyDayTmrw·Apr 19, 2025

Interesting. What do you make of PASETO[1] and specifically PAE[2], then? [1]: https://github.com/paseto-standard/paseto-spec/blob/master/d... [2]: https://github.com/paseto-standard/paseto-spec/blob/master/d...

In A New ASN.1 API for Python

michelpp·Oct 13, 2022

Another signcryption scheme as described in the article is also implemented by the libsodium author as an extension: https://github.com/jedisct1/libsodium-signcryption It's unclear from the article if this is the same implementation age uses. Signcryption schemes are also a good candidate algorithm for replacing JWTs and PASETO as they suffer from no algorithm confusion, and don't need what PASETO calls "Algorithm Lucidity" and serve both plaintext authentication, authenticated encryption, sender receiver verification, and shared key generation that can be used for unlimited encrypted streaming, for example with libsodium's crypto_secretstream API. https://doc.libsodium.org/secret-key_cryptography/secretstre... https://github.com/paseto-standard/paseto-spec/blob/master/d...

In Age and Authenticated Encryption

aPoCoMiLogin·Oct 3, 2022

here's the spec and comparison: https://github.com/paseto-standard/paseto-spec

In Paseto is everything you love about JWT without any of the design deficits

CiPHPerCoder·Aug 25, 2021

> Blame the library, or its defaults. Every JWT proponent says that, but it's a misuse that shows up in multiple libraries, in multiple languages, and isn't explicitly called out in the JWT Best Practices RFC at all. I'm going to blame the standard for being error-prone. There's nothing in any JWT RFC, to date, that calls out the need for cryptographic keys to be the raw key material in addition to its parameter choices, rather than just the raw key material. That's a fault of the standard. That's not a single library's fault. That's the standard's fault. PASETO has this to say: https://github.com/paseto-standard/paseto-spec/blob/master/d... > As for the key ID attack, this sounds like it's just a trick to know where the private key is located? It shouldn't be publicly accessible. This doesn't involve private keys at all. Look at the proo

Read the rest

f of concept code. https://github.com/firebase/php-jwt/files/6966712/php-jwt-po...

In API Tokens: A Tedious Survey