3 ms·
The one approach you missed on that blog post: put an envelope inside an envelope. Does anyone ever do this? { "original":"json", "goes":"here" }
by juliusmusseau 7y ago
The one approach you missed on that blog post: put an envelope inside an envelope. Does anyone ever do this?
{
"original":"json",
"goes":"here"
}
Signed:
{
"original_json_contents_base64":"ewogICJvcmlnaW5hbCI6Impzb24iLAogICJnb2VzIjoiaGVyZSIKfQo=",
"hmac_sha256_of_base64":"bf1f4cb95ce8633aff46888e1717873e32bb2a770b3d4b5b74a59e5e9adefeda"
}
This way you have full control over the raw bytes you want to sign (by forcing them into Base64 where other systems can't get their dirty paws on them).
I guess the problem here is if intermediate systems want to do stuff based on the payload (but without validating it), they won't like this.
But if the problem is just intermediate systems barfing on non-json, this might work!
p.s. enjoyable blog post - as they always are! ;-)
- lvh 7y agoYep! That works, but it's essentially the first option ("How to sign a JSON object") but with JSON as the outer serialization format instead of a comma in the middle. You also correctly identified why that is different from the other schemes: they don't change the structure of the outer object.
- Skunkleton 7y agoYou could also serialize the json with a placeholder string (All spaces or zeroes or something), calculate the HMAC, and substitute the string. You could then do that in reverse on the receiving end. The deserialization could easily note the offset of the hmac, which could then easily be verified against the original bytes.
- lvh 7y agoHow is that distinct from the bait and switch trick in the post?