DEV Community

loading...

Discussion on: How I Fixed JWT Security Flaws in 3 Steps

Collapse
paragoniescott profile image
Scott Arciszewski

The problems with JSON Web Tokens are that it's an error-prone cryptographic design.

Most of (if not all of) the work you had to do to get JWT security flaws fixed should never have been necessary in the first place. Furthermore, there may still be as-of-yet undiscovered flaws in the JOSE standards since they do a lot of things that maximize the risk of implementation error.

You're better off implementing something less foot-bullety. I wrote PASETO to replace JWT. Maybe a good starting point?

Collapse
byrro profile image
Renato Byrro Author

Hey Scott, thanks for joining the discussion!

I very welcome this suggestion. Definitely am open to new implementations that would excel current ones, in any area. 👐

Never heard of PASETO until now. I read very quickly, but I promise I'll give proper time to familiarize myself as soon as I can. Maybe we can contribute on DEV with article about it? Let me know how the idea sounds to you.

At first glance, what I captured is:

  1. Prevents publicizing which algo is used in the token generation
    • This indeed must never be public, hence my heads-up in the article
    • I agree that having an attribute for it in the JWT original specs was a design mistake from a security standpoint
  2. Enforces asymmetric keys on public environments

Did I miss any important top-level aspect of it?

A few considerations came to my mind in order to validate the true value brought by the PASETO implementation.

Not questioning the value at this point. Sort of a peer reviewing in search for practical confirmation.

My rule - I trust it's a fair one - is: always confirm by experience before accepting something as truth. 😉

I'll get back to you when I find myself ready for a productive and intelligent discussion on the topic! 👍

Collapse
paragoniescott profile image
Scott Arciszewski • Edited

You mostly got the idea right.

The design of PASETO was influenced by a simple observation about real world cryptanalysis.

Let's say you were tasked with building a brick wall. Would you...

  1. Place each brick carefully and meaningfully and then use mortar to join them together once, OR
  2. Create a three-dimensional lattice so bricks can be hot-swapped to better fit the designer's goals and operational requirements?

Which design would you trust to hold up a roof?

Option 2 is what the JOSE standards (JWT, JWE, JWS) do. Option 1 is what PASETO does. PASETO doesn't merely hide the algorithms, it forces developers to one of two modes that have security turned up to 11, based on their specific requirements.

PASETO's design was inspired by the least controversial meta-observation in cryptography today: Cryptography vulnerabilities more often lie in the metaphorical mortar rather than the bricks.

Randal Degges gave a talk about PASETO recently. The slides are available here.

Thread Thread
byrro profile image
Renato Byrro Author

Looks good, thanks for clarifying. Will research more into it.

Collapse
byrro profile image
Renato Byrro Author • Edited

Hey Scott, it's been a long while, but I finally managed to get a bit more familiar with PASETO. Thought I could pick your brain to understand a bit more about the feasibility of the concept.

Disclosure: although I have interest in the topics as a developer, at this moment I'm far from a security or cryptography expert.

I've read this thread on IETF discussing the feasibility of adopting PASETO as a replacement for JWTs. From what I could understand, at that moment (2018), the overwhelming majority of experts in that group didn't find it a good idea to adopt PASETO as a replacement.

They seemed to value a few ideas from PASETO that could be incorporated in a new, stronger version for the JWT specification, while other parts of the PASETO specs did raise security concerns.

What is the current thought among the community experts with regards to this? Is PASETO at the point of adoption as an industry-standard?