3 ms·

This is a real production issue for me, so could you please elaborate on why you think one of these (whichever you prefer) is better or link me to a source?

CiPHPerCoder 8y ago
I'm not sure how you intended this comment, but it reads a bit like a solicitation for lvh to do free work. I wrote PASETO, with a lot of feedback from cryptographers and security engineers, to avoid a lot of the design flaws of JWT. Learn more about it here: https://paragonie.com/blog/2018/03/paseto-platform-agnostic-security-tokens-is-secure-alternative-jose-standards-jwt-etc https://paragonie.com/blog/2018/03/paseto-platform-agnostic-... You can find a lot of implementations available: https://paseto.io https://paseto.io (Also: You almost certainly want to use v2)
- madeuptempacct 8y ago
  I wanted a link to your solution because I have never heard of it before. Not sure where you are getting the "free work" part of this from, unless you want to be paid per comment. Careful with the free advertising with PASETO there. Joking on the last two sentences, but that's how you sound when you accuse me of wanting free work. Thanks for the links.
  - CiPHPerCoder 8y ago
    > Not sure where you are getting the "free work" part of this from, unless you want to be paid per comment. Oh, that's easy to explain. You said: > This is a real production issue for me, so could you please elaborate on why you think one of these (whichever you prefer) is better or link me to a source? Specifically: > This is a real production issue for me, If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction.
    - coldtea 8y ago
      >If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction. If we're being uncharitable, yes. But the parent didn't ask the other to sit down and write code, or consult, or design a system for them. In the course of an already existing discussion on the merits (and the faults) of various session auth schemes, the parent asked the other person to elaborate on why he said something. Which people do all the time without getting paid, and the grandparent was already doing (offering his opinion) anyway. So that it's a "real production issue" for them is irrelevant. I participate in conversations all the time concerning something that is a real business issue for me or the others, and nobody feels like we should be getting paid because we have a talk. In fact half of the discussions on HN concern frameworks, tools, deployment schemes, etc, we use in production, and we have "real production issues" with and are interested in getting other's opinions in the discussion. I think one can easily see how this is different from a proper consulting gig. >"If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction." That sounds like what some kind of caricature of a high street lawyer who charges from the first minute, even people they casually talk with. As if answering a comment on HN would equal to doing a consulting gig. It's doubly uncharitable since the parent asked nicely and also added "or link me to a source". Should he be charged for a link too?
      - CiPHPerCoder 8y ago
        > So that it's a "real production issue" for them is irrelevant. I respectfully disagree. If it was truly irrelevant, it didn't need to be brought up in the first place. But it was, and it's what made me believe that the other person was trying to solicit for a security expert to solve a production problem for them without an invoice being involved. It was relevant to my interpretation. They insist they didn't mean it that way, and I believe them, but it was still relevant. Whether or not it was relevant in the comment I replied to, it became relevant once it was entered into the discussion. You can call that "uncharitable" if you want. I don't really have a horse in that race.
        8y ago
  - madeuptempacct 8y ago
    @CiPHPerCoder Looks like there is a limit to reply nesting, so replying here. Come on, I asked for a link or a description. I didn't even provide a single word about our stack. Nor do I know who the guy is, or anyone on this site, for that matter.
    - CiPHPerCoder 8y ago
      I'm happy to hear you didn't mean it that way.
      - deleted 8y ago
        [deleted]
lvh 8y ago
We wrote a big-ol blog post about inter-service auth that has a lot of relevant stuff: https://latacora.micro.blog/2018/06/12/a-childs-garden.html https://latacora.micro.blog/2018/06/12/a-childs-garden.html RLS means your database understands what a user is allowed to see and not allowed to see. It is usually much simpler to express authz in a SQL constraint than it is in code. It's also harder to forget, so you don't get an authz failure in like, one endpoint.
- madeuptempacct 8y ago
  I will check it out, thanks.
- Boulth 8y ago
  I wouldn't recommend Macaroons so lightly. I spent 2 months researching them for internal use, reimplemening them from the paper and comparing with existing implementations. There are numerous practical issues with Macaroons: the caveat format is not standardized (both binary and allowed claim types), that matters a lot when using third party caveats. There are some de facto formats but they are full of issues (e.g. date format not exactly ISO). Validation of a set of Macaroons requires walking a graph, that needs cycle detection, implementations that I've checked do not allow nested third party caveats, that invalidates one reason to use them. Attenuation is nice but it doesn't play nice with third party caveats (hash is used as a key for decryption, appending to a third party caveat changes hash). Then there are implementation errors such as: https://github.com/nitram509/macaroons.js/blob/master/lib/CryptoTools.js#L51 https://github.com/nitram509/macaroons.js/blob/master/lib/Cr... Some of these issues could be removed by slightly changing implementations but the de facto implementation basically froze it. (then there is a fact that the de facto impl already changed some aspects from the paper, e.g. calculation of hash for appended third party caveat).
- geezerjay 8y ago
  > We wrote a big-ol blog post about inter-service auth Wow what a treasure trove of goodness. Thank you!

CiPHPerCoder 8y ago

I'm not sure how you intended this comment, but it reads a bit like a solicitation for lvh to do free work. I wrote PASETO, with a lot of feedback from cryptographers and security engineers, to avoid a lot of the design flaws of JWT. Learn more about it here: https://paragonie.com/blog/2018/03/paseto-platform-agnostic-security-tokens-is-secure-alternative-jose-standards-jwt-etc https://paragonie.com/blog/2018/03/paseto-platform-agnostic-... You can find a lot of implementations available: https://paseto.io https://paseto.io (Also: You almost certainly want to use v2)

madeuptempacct 8y ago
I wanted a link to your solution because I have never heard of it before. Not sure where you are getting the "free work" part of this from, unless you want to be paid per comment. Careful with the free advertising with PASETO there. Joking on the last two sentences, but that's how you sound when you accuse me of wanting free work. Thanks for the links.
- CiPHPerCoder 8y ago
  > Not sure where you are getting the "free work" part of this from, unless you want to be paid per comment. Oh, that's easy to explain. You said: > This is a real production issue for me, so could you please elaborate on why you think one of these (whichever you prefer) is better or link me to a source? Specifically: > This is a real production issue for me, If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction.
  - coldtea 8y ago
    >If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction. If we're being uncharitable, yes. But the parent didn't ask the other to sit down and write code, or consult, or design a system for them. In the course of an already existing discussion on the merits (and the faults) of various session auth schemes, the parent asked the other person to elaborate on why he said something. Which people do all the time without getting paid, and the grandparent was already doing (offering his opinion) anyway. So that it's a "real production issue" for them is irrelevant. I participate in conversations all the time concerning something that is a real business issue for me or the others, and nobody feels like we should be getting paid because we have a talk. In fact half of the discussions on HN concern frameworks, tools, deployment schemes, etc, we use in production, and we have "real production issues" with and are interested in getting other's opinions in the discussion. I think one can easily see how this is different from a proper consulting gig. >"If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction." That sounds like what some kind of caricature of a high street lawyer who charges from the first minute, even people they casually talk with. As if answering a comment on HN would equal to doing a consulting gig. It's doubly uncharitable since the parent asked nicely and also added "or link me to a source". Should he be charged for a link too?
    - CiPHPerCoder 8y ago
      > So that it's a "real production issue" for them is irrelevant. I respectfully disagree. If it was truly irrelevant, it didn't need to be brought up in the first place. But it was, and it's what made me believe that the other person was trying to solicit for a security expert to solve a production problem for them without an invoice being involved. It was relevant to my interpretation. They insist they didn't mean it that way, and I believe them, but it was still relevant. Whether or not it was relevant in the comment I replied to, it became relevant once it was entered into the discussion. You can call that "uncharitable" if you want. I don't really have a horse in that race.
      - 8y ago
- madeuptempacct 8y ago
  @CiPHPerCoder Looks like there is a limit to reply nesting, so replying here. Come on, I asked for a link or a description. I didn't even provide a single word about our stack. Nor do I know who the guy is, or anyone on this site, for that matter.
  - CiPHPerCoder 8y ago
    I'm happy to hear you didn't mean it that way.
    - deleted 8y ago
      [deleted]

lvh 8y ago

We wrote a big-ol blog post about inter-service auth that has a lot of relevant stuff: https://latacora.micro.blog/2018/06/12/a-childs-garden.html https://latacora.micro.blog/2018/06/12/a-childs-garden.html RLS means your database understands what a user is allowed to see and not allowed to see. It is usually much simpler to express authz in a SQL constraint than it is in code. It's also harder to forget, so you don't get an authz failure in like, one endpoint.

madeuptempacct 8y ago
I will check it out, thanks.
Boulth 8y ago
I wouldn't recommend Macaroons so lightly. I spent 2 months researching them for internal use, reimplemening them from the paper and comparing with existing implementations. There are numerous practical issues with Macaroons: the caveat format is not standardized (both binary and allowed claim types), that matters a lot when using third party caveats. There are some de facto formats but they are full of issues (e.g. date format not exactly ISO). Validation of a set of Macaroons requires walking a graph, that needs cycle detection, implementations that I've checked do not allow nested third party caveats, that invalidates one reason to use them. Attenuation is nice but it doesn't play nice with third party caveats (hash is used as a key for decryption, appending to a third party caveat changes hash). Then there are implementation errors such as: https://github.com/nitram509/macaroons.js/blob/master/lib/CryptoTools.js#L51 https://github.com/nitram509/macaroons.js/blob/master/lib/Cr... Some of these issues could be removed by slightly changing implementations but the de facto implementation basically froze it. (then there is a fact that the de facto impl already changed some aspects from the paper, e.g. calculation of hash for appended third party caveat).
geezerjay 8y ago
> We wrote a big-ol blog post about inter-service auth Wow what a treasure trove of goodness. Thank you!