8 ms·

Javascript Object Signing and Encryption is a Bad Standard (2017)

173 points by xenocratus 7y ago

api 7y ago
Dynamic languages with no compile time checking of fields, assertions, etc. seem inherently very dangerous to me for anything security critical or cryptographic. Sure you can write secure and correct code in them, but what happens years later when others (including yourself after you've forgotten what you wrote!) have come and made various edits, changes, refactors, etc. This is generally where dynamic languages crash and burn, but it's particularly dangerous with stuff like authentication where a bug can be disastrous.
- onlydeadheroes 7y ago
  Indeed it is much better to implement it in a language such as C or C++ that has historically had almost no security issues and has very few pitfalls.
  - detaro 7y ago
    Please don't attack arguments the parent comment didn't make.
    - onlydeadheroes 7y ago
      Of course, because security issues and language pitfalls have no bearing on cryptographic implementations.
      - detaro 7y ago
        "Dynamic languages have issues" does not say "all other languages are good".
        wayneftw 7y ago
        In this context, where the commenter is replying to an article about a dynamic language and their comment recommends non-dynamic languages? Yeah it kinda does say something like that. Anyway, could you please not speak to people here as if you’re a moderator and leave moderation to the staff? Thanks a bunch!
        onlydeadheroes 7y ago
        He is saying dynamic languages crash and burn in this context. Specifying "dynamic" does strongly suggest non-dynamic languages do not crash and burn in this context.
    - jsjohnst 7y ago
      Or said another way (from the HN guidelines): > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
  - api 7y ago
    C's weak type system proves my point. Safer code can be written in C++ IF you take advantage of its type system to implement safety features, but the language doesn't force you to do this so there is much insecure C++ code around. Go, Rust, Java, C#, Haskell, etc. are examples of relatively safe languages with type systems that mostly keep the foot guns in the foot gun cabinet.
    - zzzcpan 7y ago
      > with type systems that mostly keep the foot guns in the foot gun cabinet They don't compared to dynamic languages. Those type systems are only an improvement compared to C and C++, not to dynamic languages.
- icebraining 7y ago
  How is that relevant to the article being discussed?
- StreamBright 7y ago
  How would you implement security for the web then?
- zzzcpan 7y ago
  > Dynamic languages with no compile time checking of fields, assertions, etc. seem inherently very dangerous to me for anything security critical or cryptographic. You don't seem to realize, but runtime checking and assertions is an equivalent thing, it's literally an empty claim. But dynamism actually allows more in terms of security, because you can track a lot of things at runtime implicitly and bail if anything doesn't satisfy some property. For example: taint checking https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking > Sure you can write secure and correct code in them, but what happens years later when others (including yourself after you've forgotten what you wrote!) have come and made various edits, changes, refactors, etc. That's what test coverage is for. But your claims are wrong and ignorant either way. We have empirical evidence that less code means less bugs and that more expressive dynamic languages means less code for the same functionality and therefore less bugs too.
- simiones 7y ago
  Can you cite any reason for this belief? All comparisons of dynamic languages vs statically-typed languages have found 0 or extremely minor effects on correctness.
jchanimal 7y ago
I found Cisco’s wrappers for WebCrypto implementing JOSE to be good and I don’t plan to avoid it. https://github.com/cisco/node-jose https://github.com/cisco/node-jose
- detaro 7y ago
  What about those wrappers avoids the problems described in the article?
  - jchrisa 7y ago
    I’m pretty sure they make it hard to shoot yourselves in the foot. It’s been a while.
    - bvrmn 7y ago
      No, by default library allow "none" alg. And there is no mandatory option to limit algs. Your foot is no more. var DEFAULT_OPTIONS = { algorithms: "*", allowEmbeddedKey: false };
thefounder 7y ago
Sure JOSE is bad but the author gives no real alternatives to JOSE. A session cookie has little in common with JOSE. The author ignores the need for SSO and distributed authentication. The idp is free to use whatever algo it wants even if it's not in the algo list from the linked RFCs. Whoever wants to authenticate can surely implement the given algo(Most likely it just needs to import it from a standard library.)
- icebraining 7y ago
  > the author gives no real alternatives to JOSE. He does that right below the title: "Update (March 2018): Paseto is a Secure Alternative to the JOSE Standards (JWT, etc.)"
  - thefounder 7y ago
    I can't find the specification/rfc of Paseto. It looks more of a php lib. To me it seems the author is not familiar with JWT[0] and tries to solve the wrong problems(e.g assumes the idp or library being used are compromised.) [0] >> This decodes to: Version: v2 Purpose: local (shared-key authenticated encryption) Payload (hex-encoded): JWT has an 'aud' param that serves the same purpose as "Purpose" here and more. Versioning makes it even worse and doesn't solve any security issue. If v1 is compromised the client should not be allowed to use it.
    - fraktl 7y ago
      From your two comments, it's clear you skimmed the text you're trying to discuss here. How can your opinion be regarded as relevant in any way? You highlight that author is not familiar with something (he is, he's actually well respected expert who explains everything in fine detail), yet you've shown you don't read carefully at all. I found PASETO's website, rfc and github within.. 3 seconds of using my PC. I'm 100% sure you're capable of doing the same. Your comment looks like unnecessary criticism because you feel provoked since someone criticized a piece of technology you use.
      - 7y ago
bshacklett 7y ago
> If you need some bizarre stateless property for horizontal scaling your sessions... > It is overwhelmingly likely that you do not needed crazy horizontal scaling schemes at all, and that a single server-side session management system is sufficient for your use case... This feels quite short-sighted to me, even in 2017. Architecture for supporting highly available systems and so-called "crazy" horizontal scaling are not so different from each other, and pretty much everyone can benefit significantly from a highly available and fault tolerant architecture. Stateless application architecture is significantly helpful in keeping a system simple and easy to deploy, which has huge impacts on overall development processes, ability to remediate vulnerabilities and ability to respond to changing requirements.
- andybak 7y ago
  > pretty much everyone can benefit significantly from a highly available and fault tolerant architecture. Yes but these are very hard problems and you've only given one side of the cost benefit equation.
  - bshacklett 7y ago
    What are the problems that haven't been solved? Stateless application servers have been reasonably commonplace for years, now, which is the main hurdle that I've needed to surmount. The majority of other issues can be handled at the platform level. It's a lot of work to refactor an application, and sometimes that doesn't make sense, but a blanket dismissal of the usefulness of proper architecture because an application isn't running at Google or Facebook's scale does little to help push technology and practices forward.
sascha_sl 7y ago
Oh yes, throw out OIDC and let's go back to SAML. While I understand that complexity in standards might be bad because they allow you to shoot yourself in the foot, I am definitely not going to stop using JWKs with JWT/JWS, those formats are actually quite simple and have allowed us to deploy authenticating proxies essentially everywhere instead of network based access control (which was always kind of broken), with slow key rotation included (thanks keycloak) Libraries should require the user to use pinned algos. Period.
- CiPHPerCoder 7y ago
  > Oh yes, throw out OIDC and let's go back to SAML. Aside from tptacek's observation: What prohibits the development of an OpenID Connect PASETO variant? (This is a rhetorical question.)
  - sascha_sl 7y ago
    Adoption? Standardization? Not everything is a green field. Yes, I get to deal with SAML a lot, and with how quirky and incomplete and outright non-standard compliant some implementations, particularly for SaaS services are (and how there are always guides for Auth0, Otka and maybe ADFS, but never in plan SAML 2.0 terms), but we also use OIDC for a few more modern services, like Kubernetes and our own proxy and the amount of troubleshooting required has been essentially zero.
    - CiPHPerCoder 7y ago
      > Adoption? Standardization? Working on that. One of the goals of the PASETO project is to eliminate the use of JWT in modern standards, not to eliminate the standards that currently (but hopefully, temporarily) use JWT.
- tptacek 7y ago
  "Go back" to SAML? SAML is the industry standard for SSO.
Diggsey 7y ago
Great article and I agree with all of the criticisms. There is a big problem with internet standards where the "division of thought" leaves a gap in the middle. The standard author thinks "I am just designing a template for people to follow, it's up to the implementor to consider whether what they're doing actually makes sense for their use-case" and the person implementing that standard thinks "I have implemented it exactly as described, therefore all uses must be sane/secure/whatever". For example, the HTTP signatures draft standard: https://tools.ietf.org/id/draft-cavage-http-signatures-12.html https://tools.ietf.org/id/draft-cavage-http-signatures-12.ht... It specifies a pattern for signing and verifying HTTP requests. You can choose what headers to include in the signature. Now "obviously" any implementation of this standard should require you to specify up-front what headers clients must include in the signature for a request to be valid, but the specification does not mention this at all in the verification section, and none of the reference implementations actually allow you to do this! So as an attacker, I can craft any request I want and just tell the server "I'm not including any headers in the signature". Similarly: you can include the date header in the signature to help prevent replay attacks, but nowhere does it say that you probably want to check that the date on the request is actually within some threshold of the current time. And again: you can include the message digest in the signature, but nowhere does it say that you should actually verify that digest against the body. Worse, message digests are an entirely separate spec and no constraints are given about what digest algorithms should be used (many of them are not designed to be cryptographically secure). On top of that, message digests only make sense on requests with a body, so even if your library has support for "require certain headers to be present", there is likely no way to only enforce that a digest header is present for requests with a body.
- philsnow 7y ago
  The "division of thought" you talk about is the opposite of "opinionated" designs/standards. The former assumes that the reader is going to take their time, think about their own implementation and their own specific use case, and make several careful decisions about how to make it work. The latter assumes that ain't no reader got time fo dat, and is going to try to npm install any packages that have the same name as keywords in the title of your standard and assume that they're fine. Development these days is unfortunately slanted towards the latter at a lot of companies who only measure output on number of features you've shipped or the impact of products you've launched, so every incentive there is to ship things as soon as you can. However, there's no field in package repository metadata that says "this package has sharp edges, use with care" or "this package comes with safe defaults, but use with care nonetheless".
skrebbel 7y ago
If you, like me, prefer HN comments over articles: The author does not just complain about JOSE and JWT but he also designed an alternative, PASETO: https://paseto.io/ https://paseto.io/ Here's a nice PASETO write-up from Okta, a reputable third party: https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-to-paseto https://developer.okta.com/blog/2019/10/17/a-thorough-introd... PASETO looks excellent to me, in that it's proper developer friendly and makes it hard for non crypto nerds like me to shoot themselves in the foot. I can't wait for it to replace JWT in popularity.
- badrabbit 7y ago
  That's nice and all but standards exist for a reason. You ask devs to use it in order to be compliant. Regardless of merits, you can't ask people who are not knowledgable about crypto to use a library by some guy/corp just because you think it has better merits. I mean, I guess you can and some will listen but only a few. Most webdevs for non-web businesses are happy to go with a standard so if something goes wrong they don't get blamed for picking it. And many security/vulnerability pros agree with that line of thinking as well. In practice,if paseto is better I think an internet draft is in order. If JSOE is bad by commonly accepted security measurements then shouldn't the ietf wg have a mailing list where these shortcomings can be discussed and fixed?
  - CiPHPerCoder 7y ago
    > In practice,if paseto is better I think an internet draft is in order. https://paseto.io/rfc/ https://paseto.io/rfc/
    - badrabbit 7y ago
      It would be great if it at least becomes a draft. Did IETF simply ignore the proposal since 2018?
      - CiPHPerCoder 7y ago
        No, it became a draft. It just hasn't become a RFC. See: https://github.com/paragonie/paseto/issues/108 https://github.com/paragonie/paseto/issues/108
rvz 7y ago
TLDR: Use PASETO [0] or its simpler alternative Branca [1]. JWT/JWS/JWE are classic examples of bad standards that the industry has chosen to adopt because everyone else is using it. It is a downgrade in terms of usability, cryptography and even in some cases performance. As for sessions, just don't even think about using it with that. Just use PASETO [0] or Branca [1] tokens which are clearly both actively worked on secure alternatives to JWT which make it harder to shoot yourself in the foot with usability. [0] https://paseto.io https://paseto.io [1] https://branca.io https://branca.io
dangerface 7y ago
Name a security standard written by some one other than DJB that doesn't recommend bad defaults. It's almost as tho a three letter agency with more money than sense is just paying people to write weak standards. Just because the security idea can and is done poorly doesn't mean that the idea is inherently insecure. We need to see security as an ongoing process not a one time fire and forget thing. Security like encryption always gets weaker it doesn't get stronger. It's a bad idea to dismiss JWT or similar because the standard has gotten weaker as our understanding gets better.
- CiPHPerCoder 7y ago
  > Name a security standard written by some one other than DJB that doesn't recommend bad defaults. Sure, here's one at random: https://github.com/awslabs/aws-encryption-sdk-specification https://github.com/awslabs/aws-encryption-sdk-specification DJB is not one of the authors of that specification. ;)
  - skrebbel 7y ago
    Obviously you're too humble to plug your own efforts, but isn't "sensible defaults" the whole point of PASETO as well?
Autowired 7y ago
> invites developers to come up with clever explanations and workarounds instead of careful engineering I don't like the accusative tone when talking engineering. There are plenty of good reasons not to use server-side sessions, including the need to replicate them between nodes, or otherwise offload them to an external database, and if you do it asynchronously you have to make your clients sticky. People use JWT to achieve statelessness, which makes it easier to increase availability.
- CiPHPerCoder 7y ago
  > I don't like the accusative tone when talking engineering. That's fair. I wrote this in 2017 to give a single page arguments against the JOSE standards. The accusative tone is required by the fact that the entire page exists to attack the standard, based on technical arguments. The target audience of the Paragon Initiative blog has always been "PHP developers", and PHP gives you a built-in session mechanism. Which, if you're writing PHP, you should just use. Session security in modern PHP boils down to "use HTTPS". If you're doing some massively distributed system (the likes of a FAANG company project), you can disregard the advice aimed at LAMP stacks.
wadkar 7y ago
If you like video consumption, a DEFCON 2018 talk by the author Scott Arciszewski on this same topic can be found here: No Way JOSE! Designing Cryptography: https://www.youtube.com/watch?v=RijGNytjbOI https://www.youtube.com/watch?v=RijGNytjbOI You're welcome :) Edit: Clarify that Scott is the author of both post and video.
steve76 7y ago
Don't use JWT doesn't mean don't use tokens. http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... Under microservices: > For a stateless service, there's no session at all, so you simply have the application server hand out short-lived, single-use tokens for each individual authorized operation. > For a stateful service, you hand out a new short-lived, single-use token for each service - which is then exchanged on the service itself, for a session on that specific service. You never use the token itself as the session. Today I use static site generators to get rid of servers entirely. User writes to their device. Data is shared P2P.

173 points by xenocratus 7y ago

api 7y ago

Dynamic languages with no compile time checking of fields, assertions, etc. seem inherently very dangerous to me for anything security critical or cryptographic. Sure you can write secure and correct code in them, but what happens years later when others (including yourself after you've forgotten what you wrote!) have come and made various edits, changes, refactors, etc. This is generally where dynamic languages crash and burn, but it's particularly dangerous with stuff like authentication where a bug can be disastrous.

onlydeadheroes 7y ago
Indeed it is much better to implement it in a language such as C or C++ that has historically had almost no security issues and has very few pitfalls.
- detaro 7y ago
  Please don't attack arguments the parent comment didn't make.
  - onlydeadheroes 7y ago
    Of course, because security issues and language pitfalls have no bearing on cryptographic implementations.
    - detaro 7y ago
      "Dynamic languages have issues" does not say "all other languages are good".
      - wayneftw 7y ago
        In this context, where the commenter is replying to an article about a dynamic language and their comment recommends non-dynamic languages? Yeah it kinda does say something like that. Anyway, could you please not speak to people here as if you’re a moderator and leave moderation to the staff? Thanks a bunch!
      - onlydeadheroes 7y ago
        He is saying dynamic languages crash and burn in this context. Specifying "dynamic" does strongly suggest non-dynamic languages do not crash and burn in this context.
  - jsjohnst 7y ago
    Or said another way (from the HN guidelines): > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
- api 7y ago
  C's weak type system proves my point. Safer code can be written in C++ IF you take advantage of its type system to implement safety features, but the language doesn't force you to do this so there is much insecure C++ code around. Go, Rust, Java, C#, Haskell, etc. are examples of relatively safe languages with type systems that mostly keep the foot guns in the foot gun cabinet.
  - zzzcpan 7y ago
    > with type systems that mostly keep the foot guns in the foot gun cabinet They don't compared to dynamic languages. Those type systems are only an improvement compared to C and C++, not to dynamic languages.
icebraining 7y ago
How is that relevant to the article being discussed?
StreamBright 7y ago
How would you implement security for the web then?
zzzcpan 7y ago
> Dynamic languages with no compile time checking of fields, assertions, etc. seem inherently very dangerous to me for anything security critical or cryptographic. You don't seem to realize, but runtime checking and assertions is an equivalent thing, it's literally an empty claim. But dynamism actually allows more in terms of security, because you can track a lot of things at runtime implicitly and bail if anything doesn't satisfy some property. For example: taint checking https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking > Sure you can write secure and correct code in them, but what happens years later when others (including yourself after you've forgotten what you wrote!) have come and made various edits, changes, refactors, etc. That's what test coverage is for. But your claims are wrong and ignorant either way. We have empirical evidence that less code means less bugs and that more expressive dynamic languages means less code for the same functionality and therefore less bugs too.
simiones 7y ago
Can you cite any reason for this belief? All comparisons of dynamic languages vs statically-typed languages have found 0 or extremely minor effects on correctness.

jchanimal 7y ago

I found Cisco’s wrappers for WebCrypto implementing JOSE to be good and I don’t plan to avoid it. https://github.com/cisco/node-jose https://github.com/cisco/node-jose

detaro 7y ago
What about those wrappers avoids the problems described in the article?
- jchrisa 7y ago
  I’m pretty sure they make it hard to shoot yourselves in the foot. It’s been a while.
  - bvrmn 7y ago
    No, by default library allow "none" alg. And there is no mandatory option to limit algs. Your foot is no more. var DEFAULT_OPTIONS = { algorithms: "*", allowEmbeddedKey: false };

thefounder 7y ago

Sure JOSE is bad but the author gives no real alternatives to JOSE. A session cookie has little in common with JOSE. The author ignores the need for SSO and distributed authentication. The idp is free to use whatever algo it wants even if it's not in the algo list from the linked RFCs. Whoever wants to authenticate can surely implement the given algo(Most likely it just needs to import it from a standard library.)

icebraining 7y ago
> the author gives no real alternatives to JOSE. He does that right below the title: "Update (March 2018): Paseto is a Secure Alternative to the JOSE Standards (JWT, etc.)"
- thefounder 7y ago
  I can't find the specification/rfc of Paseto. It looks more of a php lib. To me it seems the author is not familiar with JWT[0] and tries to solve the wrong problems(e.g assumes the idp or library being used are compromised.) [0] >> This decodes to: Version: v2 Purpose: local (shared-key authenticated encryption) Payload (hex-encoded): JWT has an 'aud' param that serves the same purpose as "Purpose" here and more. Versioning makes it even worse and doesn't solve any security issue. If v1 is compromised the client should not be allowed to use it.
  - fraktl 7y ago
    From your two comments, it's clear you skimmed the text you're trying to discuss here. How can your opinion be regarded as relevant in any way? You highlight that author is not familiar with something (he is, he's actually well respected expert who explains everything in fine detail), yet you've shown you don't read carefully at all. I found PASETO's website, rfc and github within.. 3 seconds of using my PC. I'm 100% sure you're capable of doing the same. Your comment looks like unnecessary criticism because you feel provoked since someone criticized a piece of technology you use.
    - 7y ago

bshacklett 7y ago

> If you need some bizarre stateless property for horizontal scaling your sessions... > It is overwhelmingly likely that you do not needed crazy horizontal scaling schemes at all, and that a single server-side session management system is sufficient for your use case... This feels quite short-sighted to me, even in 2017. Architecture for supporting highly available systems and so-called "crazy" horizontal scaling are not so different from each other, and pretty much everyone can benefit significantly from a highly available and fault tolerant architecture. Stateless application architecture is significantly helpful in keeping a system simple and easy to deploy, which has huge impacts on overall development processes, ability to remediate vulnerabilities and ability to respond to changing requirements.

andybak 7y ago
> pretty much everyone can benefit significantly from a highly available and fault tolerant architecture. Yes but these are very hard problems and you've only given one side of the cost benefit equation.
- bshacklett 7y ago
  What are the problems that haven't been solved? Stateless application servers have been reasonably commonplace for years, now, which is the main hurdle that I've needed to surmount. The majority of other issues can be handled at the platform level. It's a lot of work to refactor an application, and sometimes that doesn't make sense, but a blanket dismissal of the usefulness of proper architecture because an application isn't running at Google or Facebook's scale does little to help push technology and practices forward.

sascha_sl 7y ago

Oh yes, throw out OIDC and let's go back to SAML. While I understand that complexity in standards might be bad because they allow you to shoot yourself in the foot, I am definitely not going to stop using JWKs with JWT/JWS, those formats are actually quite simple and have allowed us to deploy authenticating proxies essentially everywhere instead of network based access control (which was always kind of broken), with slow key rotation included (thanks keycloak) Libraries should require the user to use pinned algos. Period.

CiPHPerCoder 7y ago
> Oh yes, throw out OIDC and let's go back to SAML. Aside from tptacek's observation: What prohibits the development of an OpenID Connect PASETO variant? (This is a rhetorical question.)
- sascha_sl 7y ago
  Adoption? Standardization? Not everything is a green field. Yes, I get to deal with SAML a lot, and with how quirky and incomplete and outright non-standard compliant some implementations, particularly for SaaS services are (and how there are always guides for Auth0, Otka and maybe ADFS, but never in plan SAML 2.0 terms), but we also use OIDC for a few more modern services, like Kubernetes and our own proxy and the amount of troubleshooting required has been essentially zero.
  - CiPHPerCoder 7y ago
    > Adoption? Standardization? Working on that. One of the goals of the PASETO project is to eliminate the use of JWT in modern standards, not to eliminate the standards that currently (but hopefully, temporarily) use JWT.
tptacek 7y ago
"Go back" to SAML? SAML is the industry standard for SSO.

Diggsey 7y ago

Great article and I agree with all of the criticisms. There is a big problem with internet standards where the "division of thought" leaves a gap in the middle. The standard author thinks "I am just designing a template for people to follow, it's up to the implementor to consider whether what they're doing actually makes sense for their use-case" and the person implementing that standard thinks "I have implemented it exactly as described, therefore all uses must be sane/secure/whatever". For example, the HTTP signatures draft standard: https://tools.ietf.org/id/draft-cavage-http-signatures-12.html https://tools.ietf.org/id/draft-cavage-http-signatures-12.ht... It specifies a pattern for signing and verifying HTTP requests. You can choose what headers to include in the signature. Now "obviously" any implementation of this standard should require you to specify up-front what headers clients must include in the signature for a request to be valid, but the specification does not mention this at all in the verification section, and none of the reference implementations actually allow you to do this! So as an attacker, I can craft any request I want and just tell the server "I'm not including any headers in the signature". Similarly: you can include the date header in the signature to help prevent replay attacks, but nowhere does it say that you probably want to check that the date on the request is actually within some threshold of the current time. And again: you can include the message digest in the signature, but nowhere does it say that you should actually verify that digest against the body. Worse, message digests are an entirely separate spec and no constraints are given about what digest algorithms should be used (many of them are not designed to be cryptographically secure). On top of that, message digests only make sense on requests with a body, so even if your library has support for "require certain headers to be present", there is likely no way to only enforce that a digest header is present for requests with a body.

philsnow 7y ago
The "division of thought" you talk about is the opposite of "opinionated" designs/standards. The former assumes that the reader is going to take their time, think about their own implementation and their own specific use case, and make several careful decisions about how to make it work. The latter assumes that ain't no reader got time fo dat, and is going to try to npm install any packages that have the same name as keywords in the title of your standard and assume that they're fine. Development these days is unfortunately slanted towards the latter at a lot of companies who only measure output on number of features you've shipped or the impact of products you've launched, so every incentive there is to ship things as soon as you can. However, there's no field in package repository metadata that says "this package has sharp edges, use with care" or "this package comes with safe defaults, but use with care nonetheless".

skrebbel 7y ago

If you, like me, prefer HN comments over articles: The author does not just complain about JOSE and JWT but he also designed an alternative, PASETO: https://paseto.io/ https://paseto.io/ Here's a nice PASETO write-up from Okta, a reputable third party: https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-to-paseto https://developer.okta.com/blog/2019/10/17/a-thorough-introd... PASETO looks excellent to me, in that it's proper developer friendly and makes it hard for non crypto nerds like me to shoot themselves in the foot. I can't wait for it to replace JWT in popularity.

badrabbit 7y ago
That's nice and all but standards exist for a reason. You ask devs to use it in order to be compliant. Regardless of merits, you can't ask people who are not knowledgable about crypto to use a library by some guy/corp just because you think it has better merits. I mean, I guess you can and some will listen but only a few. Most webdevs for non-web businesses are happy to go with a standard so if something goes wrong they don't get blamed for picking it. And many security/vulnerability pros agree with that line of thinking as well. In practice,if paseto is better I think an internet draft is in order. If JSOE is bad by commonly accepted security measurements then shouldn't the ietf wg have a mailing list where these shortcomings can be discussed and fixed?
- CiPHPerCoder 7y ago
  > In practice,if paseto is better I think an internet draft is in order. https://paseto.io/rfc/ https://paseto.io/rfc/
  - badrabbit 7y ago
    It would be great if it at least becomes a draft. Did IETF simply ignore the proposal since 2018?
    - CiPHPerCoder 7y ago
      No, it became a draft. It just hasn't become a RFC. See: https://github.com/paragonie/paseto/issues/108 https://github.com/paragonie/paseto/issues/108

rvz 7y ago

TLDR: Use PASETO [0] or its simpler alternative Branca [1]. JWT/JWS/JWE are classic examples of bad standards that the industry has chosen to adopt because everyone else is using it. It is a downgrade in terms of usability, cryptography and even in some cases performance. As for sessions, just don't even think about using it with that. Just use PASETO [0] or Branca [1] tokens which are clearly both actively worked on secure alternatives to JWT which make it harder to shoot yourself in the foot with usability. [0] https://paseto.io https://paseto.io [1] https://branca.io https://branca.io

dangerface 7y ago

Name a security standard written by some one other than DJB that doesn't recommend bad defaults. It's almost as tho a three letter agency with more money than sense is just paying people to write weak standards. Just because the security idea can and is done poorly doesn't mean that the idea is inherently insecure. We need to see security as an ongoing process not a one time fire and forget thing. Security like encryption always gets weaker it doesn't get stronger. It's a bad idea to dismiss JWT or similar because the standard has gotten weaker as our understanding gets better.

CiPHPerCoder 7y ago
> Name a security standard written by some one other than DJB that doesn't recommend bad defaults. Sure, here's one at random: https://github.com/awslabs/aws-encryption-sdk-specification https://github.com/awslabs/aws-encryption-sdk-specification DJB is not one of the authors of that specification. ;)
- skrebbel 7y ago
  Obviously you're too humble to plug your own efforts, but isn't "sensible defaults" the whole point of PASETO as well?

Autowired 7y ago

> invites developers to come up with clever explanations and workarounds instead of careful engineering I don't like the accusative tone when talking engineering. There are plenty of good reasons not to use server-side sessions, including the need to replicate them between nodes, or otherwise offload them to an external database, and if you do it asynchronously you have to make your clients sticky. People use JWT to achieve statelessness, which makes it easier to increase availability.

CiPHPerCoder 7y ago
> I don't like the accusative tone when talking engineering. That's fair. I wrote this in 2017 to give a single page arguments against the JOSE standards. The accusative tone is required by the fact that the entire page exists to attack the standard, based on technical arguments. The target audience of the Paragon Initiative blog has always been "PHP developers", and PHP gives you a built-in session mechanism. Which, if you're writing PHP, you should just use. Session security in modern PHP boils down to "use HTTPS". If you're doing some massively distributed system (the likes of a FAANG company project), you can disregard the advice aimed at LAMP stacks.

wadkar 7y ago

If you like video consumption, a DEFCON 2018 talk by the author Scott Arciszewski on this same topic can be found here: No Way JOSE! Designing Cryptography: https://www.youtube.com/watch?v=RijGNytjbOI https://www.youtube.com/watch?v=RijGNytjbOI You're welcome :) Edit: Clarify that Scott is the author of both post and video.

steve76 7y ago

Don't use JWT doesn't mean don't use tokens. http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo... Under microservices: > For a stateless service, there's no session at all, so you simply have the application server hand out short-lived, single-use tokens for each individual authorized operation. > For a stateful service, you hand out a new short-lived, single-use token for each service - which is then exchanged on the service itself, for a session on that specific service. You never use the token itself as the session. Today I use static site generators to get rid of servers entirely. User writes to their device. Data is shared P2P.