bmersereau hardens the locks on Mike's download links

A subtle timing weakness in how the backend checks download tokens gets closed before it can ever be abused.

securityinfrastructure

When someone opens a secure download link in Mike, the backend has to confirm the token in that link is genuine. bmersereau noticed the check could finish faster when a token was the wrong length than when it was the right length but wrong content. In theory, an attacker who measured those tiny timing differences could learn things about the secret they were trying to guess - a classic side-channel trick.

bmersereau reworked the comparison so it always takes the same amount of time regardless of the input, then added a small battery of tests to prove it behaves. The team is upfront that this is belt-and-suspenders: Mike's real tokens are all a fixed length, so there was no live hole here. The point is to make the underlying check correct as a reusable pattern, so it stays safe if it is ever pointed at something riskier.

So what Anyone evaluating Mike for a security-conscious practice will appreciate a maintainer who fixes theoretical weaknesses before they become real ones.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?