为什么SlowEquals函数对比较哈希密码很重要？ [英] Why is the SlowEquals function important to compare hashed passwords?

问题描述

我最近阅读了有关密码散列和盐化的文章，其中（在SlowEquals代码如何工作？下）解释说，必须使用SlowEquals函数来将输入的密码的散列与数据库中的密码的散列进行比较。

根据我的理解，使用SlowEquals函数是因为它使用异或而不是==，因此将检查两个字符串中的每个字符，而不是在第一个不匹配的字符上失败。

有两件事我不明白：

1. 为什么XOR会继续检查


2. 如果主要想法是在尝试破解密码时不给攻击者任何有用的信息，则不会有一个随机的sleep（）函数

算法比较所有字节的生成时间，这两个哈希只是实现的结果，并且与XOR的使用无关（即可以编写一个算法，比较所有字节，而不在第一次不匹配，即使使用==）。使用XOR旨在避免在循环体中引入分支指令，这可能揭示关于作为CPU的分支预测的结果的匹配字节的数量的细节（但是这是否是一个问题将在某种程度上取决于特定实现和它编译的指令）。

使用随机sleep（）来掩盖在第一次匹配时返回的散列检查的时间并不真正工作因为通过取更多样本，仍可能在给定点处区分匹配与失配。为了论证，如果我们假设我们睡在均匀分布在[0..100]范围内的随机数毫秒，并且在某个位置的匹配需要2ms，并且在那个位置的不匹配只需要1ms（作为算法退出）。通过足够的采样，我们可以区分匹配和不匹配情况，因为我们将观察到在不匹配情况下从[1..101] ms的范围内的响应，但是在匹配情况下（2.102）ms（假设我们可以完美地时间响应） 。当然，现实世界的观察会遭受抖动和其他随机性来源，但是仍然可能观察到偏见。

然后当然只有实际的考虑 - 为什么引入睡眠，随机等等，当相对较小的修改应该导致它运行在恒定的时间，并消除时间攻击？

I recently read an article on password hashing and salting wherein it was explained (under "How does the SlowEquals code work?") that a SlowEquals function must be used to compare the hash of the password entered to the hash of the password in the database.

As I understand it the SlowEquals function is used because it uses XOR instead of == and as a result will check every character in the both strings rather than failing on the first non-matching characters.

There are two things I don't understand:

1. Why will the XOR continue to check the string after a fail condition is reached.
2. If the main idea is to not give the attacker any useful information while trying to crack a password, wouldn't a sleep() function with a randomly generated time do the trick just fine?

解决方案

The fact that the algorithm compares all bytes of the two hashes is simply a result of the implementation, and is not related to the use of XOR (i.e. one could write an algorithm that compares all bytes without breaking at the first mismatch even using ==). The use of XOR is intended to avoid introducing branching instructions in the loop body, which might reveal details as to the number of matching bytes as a result of the CPU's branch-prediction (though whether that is an issue would depend somewhat on the particular implementation, and the instructions it's compiled to).

The use of a random sleep() to mask timing of a hash check that returns at the first mismatch doesn't really work as it may still be possible to distinguish match from mismatch at a given point by taking more samples. For the sake of argument if we assume we sleep for a random number of milliseconds uniformly distributed in the range [0..100], and a match at a certain position takes 2ms and a mismatch at that position takes just 1ms (as the algorithm exits early). With sufficient sampling we could distinguish the match and mismatch cases as we would observe responses ranging from [1..101]ms in the mismatch case, but [2..102]ms in the match case (assuming we can time responses perfectly). Of course real-world observations would suffer jitter and other sources of randomness, but a bias would still potentially be observed.

Then of course there is simply the practical consideration - why introduce sleeps, randoms etc. when relatively minor modifications should result in it running in constant time, and eliminating timing attacks?

这篇关于为什么SlowEquals函数对比较哈希密码很重要？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！