比较MySQL中的字符串容易受到定时攻击吗？ [英] Is comparing strings in MySQL vulnerable to timing attacks?

问题描述

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

但是不是使用PHP函数调用来比较现在散列用户输入和存储的散列，比较在数据库中完成 - 更准确地说，使用 WHERE 子句（注意：在比较时盐因各种原因已知由于用户名是唯一的，下面的查询有效地告诉用户名和密码对是否匹配：

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

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

---

编辑：SQL注入不是一个问题，需要处理。

原则上，字符串比较（和/或索引查找）可能会泄漏密码哈希存储在数据库中的许多相同的前导字节，以及从输入的密码共享中计算出来。

原则上，攻击者可以用它反复学习密码哈希的前缀，逐字节：首先他们找到一个哈希与数据库中的散列共享第一个字节，然后共享第一个字节的两个字节，等等。

不，这样会几乎肯定无所谓。

为什么？嗯，出于以下原因：

1. 定时攻击可能允许攻击者学习部分用户的密码哈希。但是，设计良好的密码散列方案（使用salt和密钥延伸）应该保持安全（假设当然，即使攻击者知道整个密码哈希值，密码本身也不容易被猜出）。因此，即使定时攻击成功，密码本身也是安全的。

为了实施攻击，攻击者必须提交他们知道散列值的密码。哈希值取决于盐。因此，除非攻击者以某种方式已经知道盐，否则这种攻击是不可能的。 （确实，在大多数安全分析中密码散列方案中，salt被假定为公共信息，但这只是因为这种分析假设了上述最糟糕的情况，攻击者已经获得了整个用户数据库，盐和散列等的副本。如果攻击者还不知道这个散列，那么没有理由认为他们知道这个散列。） 即使攻击者知道盐，为了执行上述的迭代攻击，他们将需要生成密码，该密码将散列为具有期望前缀的值。对于任何安全的散列函数，唯一可行的方法是通过尝试一个错误，这意味着需要这样做的时间与前缀的长度成指数关系。


<这在实践中意味着，为了提取足够多的哈希位以便能够对它进行离线蛮力攻击（这不需要全部都是这些攻击;只是超过熵的有效量在密码中），攻击者需要执行尽可能多的计算来破解密码本身。对于设计良好的密码散列方案和安全选择的密码，这是不可行的。 / b>


2. 原则上，攻击者可以对攻击者进行大部分蛮力计算，结束，而只提交相当少量的密码到你的系统。但是，即使这样做，只有当他们从每个密码提交的详细和可靠的时间信息后面才会有效。实际上，实时定时攻击的效率极低，并且需要很多（通常是数千或数百万）查询来产生任何有用的信息。这很可能会抵消定时攻击可能给攻击者带来的任何潜在性能优势。

   
   
   

   这点可以放大您使用适当的密钥扩展密码哈希方案，因为这样的计划被刻意设计得很慢。因此，与首次散列密码相比，数据库中的字符串比较可能需要的时间可以忽略不计，因此由噪声造成的任何时间变化都会因噪声而丢失。

b $ b

I'm deploying a classic hashing protection for user passwords. The submitted password on login is salted, hashed, and then compared to the already stored hash in the database.

But instead of using a PHP function call to compare the now hashed user input and the stored hash, the comparison is done in database - more precisely, using a WHERE clause (NOTE: the salt is already known for various reasons at the time this comparison begins, but the password is not).

Since usernames are unique, the following query effectively tells if the username + password pair is a match or not:

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

Is this approach vulnerable to timing attacks?

---

EDIT: SQL injection is not a concern, it is taken care of.

解决方案

Yes, the string comparison (and/or index lookup) may, in principle, leak how many identical leading bytes the password hash stored in the database and the one computed from the entered password share.

In principle, an attacker could use this to iteratively learn a prefix of the password hash, byte by byte: first they find a hash that shares its first byte with the hash in the database, then one that shares its first two bytes, and so on.

No, this will almost certainly not matter.

Why? Well, for a number of reasons:

1. A timing attack may allow the attacker to learn a part of the user's password hash. A well-designed password hashing scheme (using a salt and key stretching), however, should remain secure (assuming, of course, that the passwords themselves are not easily guessable) even if the attacker knows the entire password hash. Thus, even if the timing attack succeeds, the passwords themselves will be safe.

2. To carry out the attack, the attacker must submit passwords whose hash value they know. The hash value depends on the salt. Thus, unless the attacker somehow already knows the salt, this attack is not possible.

   (It is true that, in most security analyses of password hashing schemes, the salt is assumed to be public information. However, this is only because such analyses assume the worst-case scenario mentioned above, where the attacker has already obtained a copy of the entire user database, salts and hashes and all. If the attacker doesn't yet know the hash, there's no reason to assume they would know the salt.)

3. Even if the attacker knows the salt, in order to carry out the iterative attack described above, they'll need to generate passwords that hash to a value with a desired prefix. For any secure hash function, the only practical way to do this is by trial an error, which means that the time needed to do so scales exponentially with the length of the prefix.

   What this means in practice is that, in order to extract sufficiently many bits of the hash to be able to carry out an offline brute force attack against it (which need not be all of them; just more than the effective amount of entropy in the password), the attacker needs to carry out about as much computation as required to crack the password itself. For a well designed password hashing scheme, and a securely chosen password, this is not feasible.

4. What the iterative attack can give the attacker, in principle, is the ability to do most of the brute force computation locally at their end, while only submitting a fairly small number of passwords to your system. However, even this only holds if they receive detailed and reliable timing information back from each password submitted. In practice, real timing attacks are extremely inefficient, and require many (often thousands or millions) queries to yield any useful information at all. This will very likely cancel out any potential performance advantage that the timing attack could provide for the attacker.

   This point is amplified you use a proper key-stretching password hashing scheme, since such schemes are deliberately designed to be slow. Thus, the string comparison in the database will likely take a negligible amount of time compared to hashing the password in the first place, and any timing variations caused by it will thus be lost in the noise.

这篇关于比较MySQL中的字符串容易受到定时攻击吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！