php - 比较 MySQL 中的字符串是否容易受到定时攻击？

Question

我正在为用户密码部署经典的哈希保护。登录时提交的密码被加盐、散列，然后与数据库中已经存储的散列进行比较。

但不是使用 PHP 函数调用来比较现在散列的用户输入和存储的散列，而是在数据库中进行比较 - 更准确地说，使用 WHERE子句(注意:在此比较开始时，由于各种原因，盐已经知道，但密码不知道)。

由于用户名是唯一的，因此以下查询有效地判断用户名 + 密码对是否匹配:

SELECT * FROM `users` WHERE `password`='$password_hash' AND `username`='$username';

这种方法容易受到定时攻击吗？

编辑 : SQL 注入(inject)不是问题，它被处理了。

Answer 1

是的，字符串比较(和/或索引查找)原则上可能会泄露存储在数据库中的密码哈希值和从输入的密码共享中计算出的相同前导字节的数量。

原则上，攻击者可以使用它来逐字节迭代地学习密码哈希的前缀:首先他们找到一个与数据库中的哈希共享其第一个字节的哈希，然后找到一个共享其前两个字节的哈希，以此类推在。

不，这几乎肯定无关紧要。

为什么？嗯，有几个原因:

定时攻击可能允许攻击者获知用户密码哈希的一部分。然而，即使攻击者知道整个密码散列，一个精心设计的密码散列方案(使用盐和 key stretching)也应该保持安全(当然，假设密码本身不容易被猜到)。因此，即使定时攻击成功，密码本身也是安全的。

为了进行攻击，攻击者必须提交他们知道哈希值的密码。哈希值取决于盐。因此，除非攻击者不知何故已经知道盐，否则这种攻击是不可能的。

(确实，在大多数密码散列方案的安全分析中，salt 被假定为公共(public)信息。然而，这只是因为这种分析假设了上述最坏的情况，攻击者已经获得了整个用户数据库、盐和散列等等。如果攻击者还不知道散列，就没有理由假设他们会知道盐。)

即使攻击者知道盐值，为了执行上述迭代攻击，他们也需要生成哈希到具有所需前缀的值的密码。对于任何安全散列函数，唯一可行的方法是试错，这意味着这样做所需的时间随着前缀的长度呈指数增长。

这在实践中意味着，为了提取足够多的哈希位，以便能够对其进行离线蛮力攻击(不必是所有这些位；只需超过密码)，攻击者需要执行与破解密码本身一样多的计算。 对于设计良好的密码散列方案和安全选择的密码，这是不可行的。

原则上，迭代攻击可以赋予攻击者的是在本地完成大部分蛮力计算的能力，同时只向您的系统提交相当少量的密码。但是，只有当他们从每个提交的密码中收到详细且可靠的时间信息时，这种情况才成立。在实践中，实时定时攻击效率极低 ，并且需要许多(通常是数千或数百万)查询才能产生任何有用的信息。这很可能会抵消定时攻击可能为攻击者提供的任何潜在性能优势。

这一点被放大了，您使用了适当的 key 扩展密码散列方案，因为这些方案被故意设计为很慢。因此，与首先对密码进行散列相比，数据库中的字符串比较可能会花费可以忽略不计的时间，因此由它引起的任何时间变化都将丢失在噪音中。