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:
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
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.
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...
Place each brick carefully and meaningfully and then use mortar to join them together once, OR
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.
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:
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! 👍
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...
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.
Looks good, thanks for clarifying. Will research more into it.