2

对不起,如果这是一个奇怪的问题。

我其实对定时攻击很好奇,所以我做了一些研究并理解了这个概念。我明白了,代码如下:

if token == password:
    print('Welcome')
else:
    print('Wrong password')

相当于:

def equal(s1, s2):
    if len(s1) != len(s2):
        return False

    for i in range(len(s1)):
        if s1[i] != s2[i]:
            return False
    return True

PS - 我正在使用 python 3.9.2

所以我制作了一个易受攻击的代码,如下所示:-

f = open('pass.txt', 'r')
password = f.read()
f.close()

def equal(s1, s2):
    if len(s1) != len(s2):
        return False

    for i in range(len(s1)):
        if s1[i] != s2[i]:
            return False
    return True

def login(upass):
    if equal(upass, password):
        print('Login successful')
    else:
        print('Login failed')

login()

这个简单的程序会将用户给定的密码(通过upass参数)与存储在同一目录中的文件pass.txt中的密码进行比较。如果密码匹配,那么它会用欢迎消息问候用户,否则,它会提醒用户登录失败。

假设:-

  1. 密码长度为 4 个字符。
  2. 它只是大写字母(没有数值或特殊字符)。

我可以使用以下方法利用密码:-

def attack():

    leaked = ''

    for i in range(4):

        result = { letter : 0 for letter in ascii_uppercase }

        for _ in range(50000):
            for letter in ascii_uppercase:
                string = leaked + letter + '.' * ( 4 - len(leaked) - len(letter) )
                start = time_ns()
                login(string)
                end = time_ns()
                result[letter] += end - start

        leaked += sorted(result.items(), key = lambda item : item[1], reverse=True)[0][0]
        print(leaked)

我得到了TEST正确的输出。但是,您可以清楚地看到我没有使用==字符串比较,实际上我使用的是它的等效方法。所以我决定切换回==并检查我的漏洞利用是否有效。所以我将equal()方法修改为:-

def equal(s1, s2):
    # if len(s1) != len(s2):
    #   return False

    # for i in range(len(s1)):
    #   if s1[i] != s2[i]:
    #       return False
    # return True

    if s1 == s2:
        return True
    else:
        return False

所以使用这段代码,当我调用该attack方法时,令我惊讶的是它给了我非常奇怪的结果。当我多次运行它时,我得到了以下输出:AOAD, BVCB& LGAZ。这显然不是pass.txt文件中存储的密码。

所以我的问题是,是==不是容易受到定时攻击?

4

2 回答 2

4

TL;DR 是的,它很脆弱!但是,您仍然应该使用==比较,因为这是最好的东西。


的实现str.__eq__()是否容易受到定时攻击很容易验证。让我们像这样定义四个字符串:

import random

# Lots of random characters from A to Z
s1 = ''.join(chr(random.randint(65, 90)) for _ in range(1000000))


s1c = s1                      # This string is equal and at the same memory location
s2 = ''.join(c for c in s1)   # This string is equal but not at the same memory loc
s3 = s1[:-1] + "?"            # This is not equal because of a mismatch at the end
s4 = "?" + s1[1:]             # This is not equal because of a mismatch at the start
s5 = s1[:-1000]               # This is not equal because of mismatched lengths

要计时相等检查,我们可以使用该timeit模块。

import timeit

t1_1c = timeit.timeit('s1 == s1c', 'from __main__ import s1, s1c', number=10000)
t1_2  = timeit.timeit('s1 == s2', 'from __main__ import s1, s2', number=10000)
t1_3  = timeit.timeit('s1 == s3', 'from __main__ import s1, s3', number=10000)
t1_4  = timeit.timeit('s1 == s4', 'from __main__ import s1, s4', number=10000)
t1_5  = timeit.timeit('s1 == s5', 'from __main__ import s1, s5', number=10000)

我得到以下数字:

多变的 价值
t1_1c 0.0003349999997226405
t1_2 0.7978945999993812
t1_3 0.7638719000005949
t1_4 0.0011733000001186156
t1_5 0.0003372000001036213

显然,同一内存位置的字符串报告它们几乎立即相等,但我们不希望在现实情况下会出现这种情况。开始时有错误的字符串报告“不等于”的时间比最后有错误的字符串要少几个数量级,因此我认为您的发现并不广泛适用。这可能是版本/操作系统问题,或者TEST字符串太短而无法真正注意到任何这些问题。


也许改变不匹配的位置会提供一些见解?这么长的字符串似乎有点过头了,所以我要把它的大小减小一个数量级


s1 = ''.join(chr(random.randint(65, 90)) for _ in range(100000))

timings = []
for i in range(len(s1)):
    # Force a mismatch at index i
    s_temp = s1[0:i] + "?" + s1[i+1:]
    tm = timeit.timeit('s1 == s_temp', 'from __main__ import s1, s_temp', number=100)
    print(f"\r{i/len(s1)*100:.2f}".ljust(20, " "), end="")
    timings.append(tm)

将其与不匹配的位置绘制成以下(绝对不是恒定的)图:

在此处输入图像描述

红点是字符串相等时(没有不匹配)。很明显,不匹配的字符串越往下,相等检查所需的时间就越长。如果我们将传播归因于我的计算机也在处理其他事情这一事实,并且只看这个形状的下边缘,它看起来相当线性(y 轴是对数,如果你愿意,这里是线性轴),所以它会为该str.__eq__()方法以线性时间运行取决于它需要检查多少个字符的论点增加一些分量。


总结一下,

  1. 不,==orstr.__eq__()方法对定时攻击是不安全的您的密码"TEST"太小,无法看到比较时间的影响。
  2. 是的,您应该使用==字符串比较,因为这是检查字符串相等性的正确方法。
  3. 正如@MisterMiyagi评论中指出的那样,针对定时攻击的正确防御措施是迫使您的响应延迟比处理长的错误密码所需的时间更长,而不是依靠其他操作来提供延迟。
于 2021-05-11T18:42:39.560 回答
1

半有用的答案:我不确定 的内部实现==,但作为一般规则:随着更多操作发生以区分两个值是否相等,该方法更容易受到定时攻击。因此,在您的示例中,该equal方法除了“从两个值中逐个字符地进行比较,然后进行比较”之外,它在幕后肯定会扩展到更多的操作,而不仅仅是“获取两个内存位置并从那里判断 X 字节on are equal”(我想这==或多或少是这样做的)。“取出字符 X”在这里很贵(我猜)。

我想你只是证明它不脆弱^^

于 2021-05-11T15:21:39.613 回答