Release proposal: 2.0.0

[UlisesGascon]

Main Changes

Breaking changes

• Add Node@18 as the minimum version (72f925c)

Other changes

• Adapt CI to run on Node@18 and above (3d101c4)
• Rewrite to ES6 (b89021a)
• Improve documentation (20d8b40)
• Refactor Timing Safe Equal comparative using crypto library (e49b536). This remove a dependency

[inigomarquinez]

A couple of comments added

[inigomarquinez]

LGTM

[UlisesGascon]

@lirantal any chance you can review this? 🙏

[lirantal]

Using timingSafeEqual is indeed the best practice to follow for a timing safe comparison to avoid TOCTOU and side channel attacks that leak information about the username and password being used.

However, secure timing comparison is useful when you are comparing hashes which always produce the same length, regardless of the input string length. Here, you are padding it, which could also end up with false positives. Buffer.alloc() will pad with zero length strings (`\x00') and if the input provided to you includes that byte sequence you'd have a false positive. Here's an example based on the above:

const res = callbackComparison("user", "pass", "user\x00", "pass");
console.log("Zero Padding Result:", res);

You'd expect res to be false but it is actually true.
You could fix it by filling with another byte like ... Buffer.alloc(maxLength - buf.length, 0x01)])); but my recommendation would be to completely drop the padding altogether and keep it simple and rely on the timingSafeEqual to either throw if the length is different (which is ok and not a timing leak) or perform secure comparison if the length is the same.