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.
- 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.
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.
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.
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.