-
-
Save tobyurff/f40dcac7a4671f465dcc902afa6a91be to your computer and use it in GitHub Desktop.
const crypto = require('crypto'); | |
const hmac = crypto.createHmac('SHA256', 'my-webhook-secret'); | |
hmac.update('{ ... }'); // request body | |
const correctHash = hmac.digest().toString('hex'); | |
const receivedHash = '...'; // e.g. req.get('x-impala-signature'); | |
/* | |
* It's important to perform a constant time equality comparison of the | |
* two HMACs to avoid timing attacks. | |
* | |
* See: https://en.wikipedia.org/wiki/Timing_attack | |
*/ | |
if ( | |
crypto.timingSafeEqual( | |
Buffer.from(correctHash), | |
Buffer.from(receivedHash) | |
) | |
) { | |
// Request is valid | |
} else { | |
throw new Error('Authentication failed.'); | |
} |
Hi @tobyurff, do you have any examples for dot net (core) by any chance?
Hi @PeterKottas! No, unfortunately we don't have anything in .NET. Hope you'll find the equivalent on the above example in .NET! Let us know if there's anything else we can help with, ideally on support@getimpala.com as that's monitored more regularly.
No problem, we figured it out in the meantime.
In case anybody is looking for implementation: https://gist.github.com/PeterKottas/d83906865a42f521586523fd54e7a6dc
Great, thanks a lot!
Hey all, just a quick note that node's default encoding for the Buffer.from function is UTF-8.
https://nodejs.org/api/buffer.html#buffer_static_method_buffer_from_string_encoding
We had a couple of issues with mismatching signatures due to this.
@PeterKottas your implementation, much like mine, might have the same issue.
@adrianvellamlt Thanks for the feedback and link, Adrian. The StackOverflow link you sent is correct although applies to a slightly different situation to ours. Whilst the examples there deal with different hash lengths we use SHA256 to hash the message body and as a result the length of the hash will be constant. The only information an attacker could determine from timing the length check would be the length of
correctHash
which is always the same and is publicly available in our documentation. For this reason doing the check wouldn’t compromise security in any way.I’ve removed the length check from the example as it wasn’t necessary and made the code less clear. The purpose it served was to speed up the process of rejecting inputs known to be incorrect and thus reduce the chances of a DoS attack. Having given it some more though it also wouldn’t massively reduce the DoS attack vector (assuming a relatively sophisticated attack) as an attacker could easily determine the correct length of the hash to trigger the constant time equality check.