我正在为用户密码部署一种经典的哈希保护机制。在登录时，提交的密码会被加盐、散列化，然后与已存储在数据库中的散列值进行比较。
但是，与其使用 PHP 函数调用来比较现在已经散列化的用户输入和存储的散列值不同，比较是在数据库中完成的，更确切地说，是使用一个 WHERE 子句（注意：由于各种原因，此时已经知道了盐，但尚未知道密码）。
由于用户名是唯一的，因此以下查询有效地确定用户名+密码是否匹配：
SELECT * FROM `users` WHERE `password`='$password_hash' AND `username`='$username';
原则上，字符串比较（和/或索引查找）可能会泄露密码哈希存储在数据库中的前导字节与输入密码计算出的哈希值之间有多少个相同的字节。
原则上，攻击者可以利用这一点逐字节地迭代学习密码哈希的前缀：首先找到一个哈希值，它与数据库中的哈希值共享其第一个字节，然后是共享前两个字节的哈希值，以此类推。
不，这几乎肯定不重要。
为什么？好吧，有很多原因：
定时攻击可能会允许攻击者学习用户密码哈希的一部分。 精心设计的密码哈希方案（使用盐和 密钥延展），即使攻击者知道整个密码哈希，也应该保持安全（当然，假设密码本身不容易被猜测）。 因此，即使定时攻击成功，密码本身也将是安全的。
要执行攻击，攻击者必须提交其已知哈希值的密码。 哈希值取决于盐。 因此，除非攻击者早已知道盐，否则攻击是不可能的。
（密码哈希方案的大多数安全分析中，确实假设盐是公共信息。 然而，这仅因为这种分析假设上述最坏情况，即攻击者已经获得了整个用户数据库，包括盐和哈希值等。 如果攻击者尚未知道哈希值，就没有理由假设他们会知道盐。）
即使攻击者知道盐，在执行上述迭代攻击之前，他们需要生成哈希值以具有所需的前缀的密码。 对于任何安全的哈希函数，唯一可行的方法是通过试错，这意味着所需的时间随前缀长度呈指数增长。
SELECT COUNT(*) AS matching_user_count, SLEEP(RAND()*0.20) AS junk
FROM `users`
WHERE `password`='$password_hash'
AND `username`='$username'
WHERE子句的近乎恒定的时间。一般情况下防止PHP时间攻击的一个解决方案是
/**
* execute callback function in constant-time,
* or throw an exception if callback was too slow
*
* @param callable $cb
* @param float $target_time_seconds
* @throws \LogicException if the callback was too slow
* @return whatever $cb returns.
*/
function execute_in_constant_time(callable $cb, float $target_time_seconds = 0.01)
{
$start_time = microtime(true);
$ret = ($cb)();
$success = time_sleep_until($start_time + $target_time_seconds);
if ($success) {
return $ret;
}
// dammit!
$time_used = microtime(true) - $start_time;
throw new \LogicException("callback function was too slow! time expired! target_time_seconds: {$target_time_seconds} actual time used: {$time_used}");
}
通过这个，你可以做到
$rows = execute_in_constant_time(function () use ($db, $password_hash, $username) {
return $db->query("SELECT * FROM `users` WHERE `password`='$password_hash' AND `username`='$username';")->fetchAll();
}, 0.01);