Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
lvh
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
44 ms
·
421.
▲
by
lvh
7y ago
(Trishank also lifts so he is a tough TUF guy.)
422.
▲
by
lvh
7y ago
Unless my memory is failing me, in the Google case it was really /userinfo (as in the OIDC Core UserInfo endpoint) and not token introspection (a "post-auth" endpoint taking a token, not a "pre-auth" one you pass a
423.
▲
by
lvh
7y ago
Ah! So you're saying I should say "Full disclosure" and not "Disclaimer"? (Or nothing at all, as I do here, I suppose :-)) Yes, you're absolutely right and I'll try to do better in the future :)
424.
▲
by
lvh
7y ago
Yeah, my default would absolutely be client certs. That's where my question about "an environment hostile to good ideas" comes from -- I was assuming the lack of HTTPS was there for a reason.
425.
▲
by
lvh
7y ago
Huh, sorry, I'm confused. What should I (not) be doing? I thought not disclosing being the author of the linked thing was poor form.
426.
▲
by
lvh
7y ago
PASETO is a marked improvement and doesn't have the specific problem mentioned here, by using versions instead of an attacker-controlled alg field. One of the things that makes "The JWT Problem" such a hard post to write (and
427.
▲
by
lvh
7y ago
I don't think that addresses the problem set out in the post. Other, non-cooperative third-party systems need to be able to parse the JSON blob as is.
428.
▲
by
lvh
7y ago
Re: OIDC providers: to be clear, you absolutely can just parse the JWT. I'm saying that (up until recently, if memory serves) e.g. the GSuite documentation told you that while you can validate a token, that's hard, and instead you
429.
▲
by
lvh
7y ago
Okiedokie. That sounds like catnip to me, so please do. Happy to sign (non-silly) mNDAs if that helps. Probably the most useful thing for me to know is: what's the algorithm for signing a URL? If everything uses a manifest API, can you
430.
▲
by
lvh
7y ago
That's true if you have the luxury of a traditional tag on the outside, but falls apart when you have systems where signatures are in-band, like SAML, which is where canonicalization shows up. (Both for UTF-8 itself, which isn't c
431.
▲
by
lvh
7y ago
Right. As I mentioned, you're just moving the signature from the blob itself to HTTPS, and if all you care about is validating a file you'd just make that a hash. Analogously to a SHASUM file, but the authentication coming from HT
432.
▲
by
lvh
7y ago
I think I may have answered your confusion in a different thread (I'm not sure I parsed your comment correctly though), but: this is about a problem that specifically occurs when you have JSON (or some other structured format) that nee
433.
▲
by
lvh
7y ago
> Not sure why you are downvoted, about 10% of the article addresses it's headline and I frankly do not get the point either. The proposed solution is in the first numbered list and between that and the conclusion list is a bunch o
434.
▲
by
lvh
7y ago
What do you want to accomplish? Do you want good implementations of cryptographic primitives, or something else? As a general rule: OpenSSL, BoringSSL if you can get away with it, don't use NSS or LibreSSL. But that presupposes that us
435.
▲
by
lvh
7y ago
That sounds like you found an alternative format where finding something canonical to sign is easy (files, the shasum CLI) and punted on canonicalizing the in-band signature (which is good!).
436.
▲
by
lvh
7y ago
> "I don't expect people to use it" just seems like the sort of awful excuse you'd usually be jumping on people for. I think it was pretty clear, by calling it a specific niche that ObjectHash does a good job of explo
437.
▲
by
lvh
7y ago
That is a healthy skepticism! I definitely would not counsel people to do it with primitives in general: it just turns out that a PRF doesn't have a complicated API and HMAC is bulletproof. More or less the only design criterium that c
438.
▲
by
lvh
7y ago
Not in the sense that the term of art "canonical", as in canonicalization, is used. UTF-8 is not canonical: different byte sequences can map to identical meanings, as covered in the post.
439.
▲
by
lvh
7y ago
The set of readers is of cardinality one in the scenario described.
440.
▲
by
lvh
7y ago
Partially yes. You don't need a pinned certificate, just working certificate validation. I am not suggesting you should never use asymmetric crypto: you should definitely use HTTPS. The question wasn't "is asymmetric crypto m
441.
▲
by
lvh
7y ago
If you write your own library to do it, there are strictly more things that can go wrong because at some point you're implementing a HMAC validation thingy. If you use a third party library, you're exposed to bugs that stem from J
442.
▲
by
lvh
7y ago
1. Step one is HTTPS. Since you control the client, ideally just one ciphersuite. Maybe pinning? But given that it's HTTP now, maybe this this is running in a production environment that's hostile to good ideas? (Of course, plain
443.
▲
by
lvh
7y ago
The nice thing about HMAC is that it's so bulletproof and easy to use. There are no footguns you introduce by using HMAC directly instead of using HS256, and there are plenty you introduce by using HS256 instead of plain HMAC.
444.
▲
by
lvh
7y ago
Oh, sure, yes, absolutely, software updates is one of the cases where you probably just want an (asymmetric) signature. (And probably TUF.) But my alternative suggestion also addresses that: in a model where you don't trust the host wi
445.
▲
by
lvh
7y ago
Definitely authenticate first! If there's anything I said that made you think otherwise, let me know: I would like to amend that so no-one else thinks I could possibly mean that. The initially recommended (unless you can do otherwise)
446.
▲
by
lvh
7y ago
What's the model where you don't trust that system not to exfiltrate data but you do trust that system not to flip the boolean that says the signature is valid at all?
447.
▲
by
lvh
7y ago
As I mentioned in that comment: the thing sending is also the thing receiving, just at a later point. So "the same key the user used to sign the request" doesn't seem to apply.
448.
▲
by
lvh
7y ago
We should write the "The JWT Problem" post one day, but this post isn't that, so I really don't want to derail the discussion. The short version is that there are flaws in the JWT specification that make certain bugs lik
449.
▲
by
lvh
7y ago
The server is trying to validate that the thing it gets back is the thing it previously sent out, so that's a different model. What concretely are you suggesting we store as if it was a password? The serialized JSON object?
450.
▲
by
lvh
7y ago
A super-awesome related project I didn't get a chance to work into this post (because it's entirely deserving of its own): https://github.com/benlaurie/objecthash To be clear: I think that's a niche use
More ›