Can a webhook carry an HMAC?

[Anonymous]

I'd like to have an outbound webhook hit a REST API endpoint in such a way that doesn't leave the API vulnerable to modified content or replay attacks. In other contexts, I'm making stateless requests to the API with an HMAC signature. Is there any chance I could do something similar in a Marketo webhook?

Thanks!

Adam

[SanfordWhiteman · Accepted solution]

No, webhooks cannot automatically carry a signature. You can of course gateway through another layer that does the signing -- but then the connection to that layer could in theory be able hijacked.

[Anonymous]

Thanks, Sanford. Are there any other recommendations out there for how to authenticate a webhook more securely than including static credentials in a header or payload?

[SanfordWhiteman]

You could create a time-sensitive hash using another webhook (on another endpoint, thus not exactly the same as the gateway idea). Then, triggering on the Data Value Changes on that hash field, pass that hash along with the second webhook call.

Again, though, that initial connection could -- across the wide world of theoretical attacks -- be compromised.

If you're deeply concerned that the SSL connection between your Marketo instance and your endpoint will be hijacked and decrypted for a replay attack, maybe webhooks aren't right for you? There's a certain level of connection-level confidence one needs to have to use 'hooks, or the Marketo REST API for that matter (which doesn't sign payloads), or the SFDC sync (uses a permanent password+token), or the Marketo UI (auth codes are effectively in-band, as they're retrieved on the same machine that initiated the login, so if you can hijack one you can hijack the other)...

[SanfordWhiteman]

OK, there's also another method I deliberately left out because it is for the truly adventurous and doesn't really have a place here. It does completely hide the HMAC generation, though. But first: will you be processing the response mapping from this webhook, or is it designed to send data and maybe just get an OK?

[Anonymous]

Intriguing!

No response mapping needed; this is meant to send data and maybe potentially get an acknowledgement that the handoff succeeded.

[Anonymous]

Also, just to be clear, it's not that I'm deeply concerned about someone unpacking our SSL sessions (at least not today..). Rather, it's a longstanding set of principles around credential handling and trusted channels. When I can figure out a way to leave a comms channel untrusted and still get the job done, I like to do it. (Darn Alice and Bob and their persistently open phone lines...)

That said, after exploring the available options, I'm not about to let the perfect become the enemy of the probably-good-enough.