chore: replace scmp with crypto.timingSafeEqual

[Methuselah96]

Fixes #1168

scmp is now deprecated and is equivalent to crypto.timingSafeEqual (which is supported by Node.js >=6.6.0)

Checklist

• I acknowledge that all my contributions will be made under the project's license
• I have made a material change to the repo (functionality, testing, spelling, grammar)
• I have read the Contribution Guidelines and my PR follows them
• I have titled the PR appropriately
• I have updated my branch with the main branch
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation about the functionality in the appropriate .md file
• I have added inline documentation to the code I modified

[Methuselah96]

Investigating failing tests

[Methuselah96]

Fixed

[imcotton]

Returning earlier would be unsafe because it would leak timing info. Suggest doing the HMAC beforehand:

const salt = crypto.randomBytes(42);
return crypto.timingSafeEqual(
  crypto.createHmac("sha256", salt).update(a).digest(),
  crypto.createHmac("sha256", salt).update(b).digest(),
);

[Methuselah96]

Hmm, I'm out of my depth here, but scmp was returning earlier based on the length, so seems like this might be a pre-existing issue

[Methuselah96]

According to this comment, it's okay to check the length first and return early if they're not equal

[Methuselah96]

However, according to this article, you should not return early and instead still compare two values. That seems like a more understandable solution to me, so I've updated the PR to that solution.

[imcotton]

Both negate when lengths differ or HMAC works.

The reason I suggested a later approach is that it is not always clear whether the input is from a or b, thus making it error-prone without context.

btw: I wrote that code snippet on Cloudflare docs.

[Methuselah96]

👍 I've updated the variable names to more clearly indicate which input is the user value and which one is the secret value and verified that we are passing the arguments in the correct order that matches the parameter order

[imcotton]

Given that it has only been used internally, I think it is good enough to make a cut. LGTM

Thanks.

[Emperiusm]

+1 from a downstream consumer.

We hit npm warn deprecated scmp@2.1.0: Just use Node.js's crypto.timingSafeEqual() during a transitive-deps audit and confirmed the only path to it is twilio@5.x → scmp. v6.0.1 still pulls scmp, so the deprecation can't be cleared by bumping the major. This PR is the only path forward — would love to see it land.

If maintainers want a small validation harness, the existing webhook/auth-token signature validators that route through scmp are well-covered by the repo's tests, so a swap-only PR like this one should be low-risk under those.