比较MySQL中的字符串容易受到时间攻击吗？

Question

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

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

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

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

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

---

编辑:SQL注入不是一个问题,它是照顾.

Answer 1

是的,字符串比较(和/或索引查找)原则上可以泄漏存储在数据库中的密码哈希与从输入的密码共享计算的密码哈希相同的前导字节数.

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

不,这几乎肯定无关紧要.

为什么？嗯,原因有很多:

1. 定时攻击可能允许攻击者学习用户密码哈希的一部分.然而,一个精心设计的密码散列方案(使用盐和密钥拉伸)应保持安全(当然,假设密码本身不易猜测),即使攻击者知道整个密码哈希.因此,即使定时攻击成功,密码本身也是安全的.

2. 要执行攻击,攻击者必须提交他们知道的哈希值的密码.哈希值取决于salt.因此,除非攻击者以某种方式已经知道盐,否则这种攻击是不可能的.

   (确实,在密码散列方案的大多数安全性分析中,盐被假定为公共信息.但是,这只是因为这种分析假设上面提到的最坏情况,攻击者已经获得了整个用户数据库,盐和哈希等等.如果攻击者还不知道哈希,那么没有理由认为他们会知道盐.)

3. 即使攻击者知道盐,为了执行上述的迭代攻击,他们也需要生成散列到具有所需前缀的值的密码.对于任何安全散列函数,唯一可行的方法是通过尝试错误,这意味着这样做所需的时间与前缀的长度成指数级地缩放.

   这在实践中意味着,为了提取足够多的哈希值,能够对它进行离线暴力攻击(不一定是所有这些;只是超过了有效的熵数量)密码),攻击者需要执行大约所需的计算来破解密码本身. 对于精心设计的密码散列方案和安全选择的密码,这是不可行的.

4. 原则上,迭代攻击可以为攻击者提供的是能够在本地进行大部分暴力计算,同时只向系统提交相当少量的密码.但是,即使这样,只有从提交的每个密码中收到详细可靠的计时信息才能保留.实际上,实时定时攻击非常低效,并且需要许多(通常是数千或数百万)查询才能产生任何有用的信息.这很可能会抵消计时攻击可能为攻击者提供的任何潜在性能优势.

   这一点被放大了你使用适当的密钥拉伸密码哈希方案,因为这样的方案是故意设计的慢.因此,与首先对密码进行散列相比,数据库中的字符串比较可能花费的时间可以忽略不计,并且由此引起的任何定时变化将因此在噪声中丢失.