Hacker News new | ask | show | jobs
by skrebbel 2315 days ago
I'm impressed that you put your money where your mouth is and built & marketed an alternative: https://paseto.io/

Anyone here got experience using Paseto in anger? (besides CiPHPerCoder who made it)

I would love a JWT-like thing that's equally common yet better designed. But especially when using it in public APIs and the likes, acceptance has to be pretty broad. Anyone got insights as to how mainstream Paseto is getting?

2 comments

> Anyone got insights as to how mainstream Paseto is getting?

Okta's a pretty big name in authn/authz and their engineers recently published an open source PASETO implementation.

https://developer.okta.com/blog/2019/10/17/a-thorough-introd...

https://github.com/paseto-toolkit/jpaseto

Judging from the number of stars of the various git repositories for different languages, there are a few people using it but not a whole lot. The most popular implementation seems to be php based. That suggest to me it's still early days for this. E.g. the Java implementation only has 13 stars, which is not a lot. Also it has a native dependency, which is not ideal. E.g. JWT has a pure Java implementation from oauth0.

JWT has been out there for a few years and there are many uses of it that are fine. I've used it in the past and it was easy set up and get started with. The main criticism seems to be that users have too much wiggle room to do silly things like using alg=noneor that certain widely used algorithm combinations have some weaknesses. I guess that's valid but not a huge concern if you know what you are doing.

Paseto looks like it improves by narrowing down the choices to some sane choices, which is a valid approach. Of course IETF could update the relevant RFCs to use the same algorithms for JWT at some point.

Popularity != value. Get over false signals.
With lots of "security best practice" crypto constructions you can quickly find yourself needing to use unreviewed and unsupported libraries. This is a different kind of security hell.

It's worst when you're publishing an API and you need to support web clients, plus android, IOS and ideally not make things super difficult for customers using say, erlang.

As someone who used to regularly recommend things like "Use a high level / simplified library - try keyczar! Or crypto_box! etc" it has been disheartening to see how almost any even slightly niche choice will quickly devolve to developers having to pull in a bunch of dodgy looking objective-c code written say, 3 years ago by a single unknown developer.

It's usually worked out better from a whole-system perspective to stick with very widely supported standards (flawed as they are) and maintain a checklist of known footguns. It makes me sad.

Of course if your crypto is opaque to clients / not part of your integration surface then you've got a lot more wiggle room.

Perhaps what I've taken the long-winded route to getting to is, for anything where interop is important, I believe that popularity is absolutely valuable due to network effects and momentum.

That is true. The real world is dirty and messy:

- supporting public LAMP apps

- database servers that have public IP addresses that are barely filtered

- boxes not getting updates

- under-secured Linux boxes with almost every option recompiled to on

- chmod 777 developers

- substituting signatures of checksums for signatures of data

- not using HMAC and opening themselves up to length-extension and chosen plaintext attacks

- storing SSL/SSH private keys unencrypted on unencrypted laptops

- downloading HR data to a laptop and leaving it

I actually was fired once from a big name university in the SF Bay Area for refusing to haphazardly ruin the network security of a credit card processing private campus network to facilitate a new vendor remoting into terminals.

Integrity through awareness/caution, processes and standard components.

Bringing in a bunch of random dependencies, regardless of license or support status, is inviting all sorts of gaping attack surfaces.

Popularity definitely is value when designing APIs for public consumption. JWT has a concrete edge here. This is why I asked HN about their opinions on Paseto, if there's a chance it'll overtake JWT/JWE in popularity, then that makes it more suitable for APIs.

In the context of security, popularity has the added benefit that there's enough eyeballs, so all bugs are shallow.

Author here. As a matter of fact, the world has already settled on JWT. Paseto is dead in the water and will never gain any traction.

Every single company has no choice but to support JWT in some capacity. Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SAML but that's a different topic).

> Paseto is dead in the water and will never gain any traction.

We'll see about that. :)

> Every single company has no choice but to support JWT in some capacity.

This will change soon.

> Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SAML but that's a different topic).

The plan for PASETO has always been to make it a JWT alternative for OIDC.

First comes the XChaCha RFC.

Second comes the PASETO RFC.

Finally, the OIDC-PASETO RFC.

1. https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03

2. https://github.com/paragonie/paseto/blob/master/docs/RFC/pas...

3. https://github.com/paragonie/paseto/issues/5

As soon as AWS supports PASETO we can talk, until that time popularity equals value.
No, I was speaking even more generally. There are thousands of mainframes still running COBOL that process trillions/billions of dollars of transactions per day. There are obscure software packages and programming languages you've never heard of doing many important, niche tasks. So no, popularity will never equal value. There is no wisdom in a mob. The. End.
Popularity has value because other people contribute to maintenance. It’s not the only value, but it’s still a necessary minimum for most library selection in professional work.
Give me a few months, then. :P

If they agree it's a good idea, it should pick up quickly.

Don't count on it. As it happens, I used to be a AWS consultant w/ a third-party preferred vendor. Their product direction involves more politics, job security and creating a labyrinthian platform that's difficult to emulate precisely.
Rooting for you! It's a good idea, and successfully popularizing it would provide a huge amount of value to the world.