Hacker News Reader

But it only tells them that it failed, not that they got closer, like with the string-comparison based one. What does that gain an attacker if you already provide other feedback about the request being invalid? And not doing so would result in a bad user experience if you have users run into a bug somewhere and it fails silently so they don't know that nothing was actually done.

View on HN

In some cases, not letting them know they've failed is nice. But the most common case to look out for is, if your auth/crypto process involves multiple steps, don't return early from it, or do anything that alters its runtime significantly. This leaks useful information in many situations. The course at http://crypto-class.org is better than me at explaining this stuff, and starts on Monday.

The leak that you're ostensibly timing is that in order to figure out how much of the candidate MAC string was valid, the target had to compare more byte, which takes more time, which adds observable lag to the error response.

Is the observable lag for a string comparison significant enough to be useful?

We're talking about such small amounts of time compared to the overhead of the full web stack.

The observable lag isn't usually significant enough if you only do it once but over many requests the stochastic factors can be compensated for.

Reply on news.ycombinator.com