这实际上是一个常见的误解，因为直觉上，添加随机延迟似乎应该会阻止定时攻击，直到您更深入地考虑它。

从理论上讲，如果您的随机延迟的长度是无限的，即[0, infinity]从那时开始，它会因为您建议的原因而挫败定时攻击。在实践中，您 A) 不想让合法用户等待无限长的登录时间，并且 B) 必须从某个有限范围内得出随机延迟[0, a]。这意味着平均而言（即有足够的样本）您只是增加a/2了时间。

因此，假设没有随机延迟，您有以下时序配置文件：

• 查询现有用户名：x ms
• 查询不存在的用户名：y ms

随着随机延迟，您现在（平均而言）：

• 查询现有用户名：x + a/2 ms
• 查询不存在的用户名：y + a/2 ms

由于x - y = (x + a/2) - (y + a/2)，攻击者仍然可以利用时间差。您唯一更改的是，除了必须过滤掉网络延迟、cpu 调度延迟、负载平衡延迟等之外，它们还必须过滤掉您有意的排序随机延迟。一次成功的定时攻击已经对每个用户名进行多次查询并取平均值，但现在他们可能必须添加更多样本才能获得“干净”的平均值。

底线：添加随机噪声可能会使攻击变慢，但不会使其变得更复杂。

防止定时攻击的唯一真正方法是确保每个可能的代码路径都花费相同的时间。

• 查询现有用户名：x ms
• 查询不存在的用户名：x ms

那么真的没有办法区分这两个。

警告！编写时不变代码可能很棘手，因此格言“不要自己动手”。如果你能找到一个已经实现时间不变性的登录管理器，那么使用它会更容易也更安全。

从理论上讲，这是行不通的。攻击者已经从网络延迟中获得了随机性，增加额外的随机性并不能阻止定时攻击，这只是意味着攻击者需要更多的数据进行分析。

实际上，由于分析所需的数据量，它可能使定时攻击不可行

但是有更好的方法来防止定时攻击。对于 Web 应用程序来说，主要是通过在固定时间执行某事来防止定时攻击。在您的示例中，这意味着您要将密码与假想的密码进行比较，即使用户名不存在。

当然，用户名通常不被视为敏感信息，如果您有注册页面，攻击者可能会对其进行暴力破解。另一方面，通常建议使密码比较时间安全。