密码依赖的迭代计算是一个好的实践吗？

Question

我考虑通过增加短密码的哈希迭代计数来提高密码安全性的可能性。

我看到这种做法的安全好处是：

• 短密码更好地保护通过使蛮力更昂贵。
• 鼓励用户使用更长的密码。

Is这是一个好的安全实践？

这是一种已经确立的有正式名称的做法吗？

我想使用的系统已经有了一个用于密码哈希器的插件架构，它没有任何集中的方式来执行密码策略，我可能也没有强制执行密码策略的授权。

我已经考虑过这种方法的可能缺点，对于每一个潜在的缺点，我都能想到为什么它不是一个问题的原因。

密码长度的潜在泄漏:由于密码数据库只存储用于较长密码的最小迭代计数，并且有效的迭代计数是动态计算的，因此数据库不能泄漏任何有关密码长度的信息。旨在推断密码长度的定时攻击也不起作用。试图强行使用密码的攻击者将看到验证密码所需的时间因密码的长度而异，而不是用户的实际密码。这意味着，执行这种攻击的攻击者不可能知道用户密码的长度。

潜在的DoS攻击:验证密码的CPU消耗增加可能是DoS攻击矢量。但是这个攻击向量已经存在，即使迭代计数是一个足够高的固定数，足以匹配一般的建议。防止这种DoS攻击的方法是限制每个客户端IP范围内的密码尝试。这种针对这类DoS攻击的防御措施仍然有效，前提是要根据CPU消耗调整允许的速率。

用户体验:登录速度的放缓可能被认为是糟糕的用户体验。我宁愿用它来激励用户使用更长的密码，并将其称为一项功能。登录时，我可以让用户知道，通过使用更长的密码，他们可以获得更快的登录。特别是，如果这可能是一个普遍的做法，它可能会给用户的期望，更长的密码更快，这将是一个胜利，对每个人。

从我的考虑，到目前为止，我只发现这个想法的好处。但我明白，我可能错过了一些缺点。对于短密码来说，为什么不应该把迭代计算得更高呢？

为了避免我所想到的任何含糊不清的想法，我在Django框架中编写了这个想法的实现。内建PBKDF2PasswordHasher和我的修改之间唯一的功能区别是这两行：

    if len(password) < recommended_length:
        iterations *= progression_factor**(recommended_length-len(password))

整个实现如下所示：

import base64
import hashlib

from django.contrib.auth.hashers import PBKDF2PasswordHasher
from django.utils.crypto import pbkdf2


def progressive_pbkdf2(password, salt, iterations, digest,
                       recommended_length, progression_factor):
    if len(password) < recommended_length:
        iterations *= progression_factor**(recommended_length-len(password))
    return pbkdf2(password, salt, iterations, digest=digest)


class ProgressivePBKDF2PasswordHasher(PBKDF2PasswordHasher):
    algorithm = "progressive_10_2_pbkdf2_sha256"

    def encode(self, password, salt, iterations=None):
        assert password is not None
        assert salt and ' not in salt
        if not iterations:
            iterations = self.iterations
        hash = progressive_pbkdf2(
            password, salt, iterations, digest=self.digest,
            recommended_length=10, progression_factor=2)
        hash = base64.b64encode(hash).decode('ascii').strip()
        return "%s$%d$%s$%s" % (self.algorithm, iterations, salt, hash)

Answer 1

你想用技术解决问题来解决人的问题。tbh，我看不出你的迭代次数的增加会“激励用户使用更长的密码”，即使你建议用户会“感觉到”更长的密码和更短的密码在速度上的差异。除非您将其设置为荒谬的值，否则用户不会注意到颠簸迭代。

那么，我们实际上讨论的是什么类型的数字，什么时候你会implement iterations *= progression_factor**(recommended_length-len(password))呢？数以万计？几十万？数百万？数十亿？您将如何教育您的用户，有经验的登录速度放缓是由于他们糟糕的密码，而不是您认为不适合编码一个行为网站？

我的意思是，当然您可以实现所有的想法，但最终，弱密码就是弱密码--不管您经常迭代PBKDF。如果您的用户正在使用123456、correct horse battery staple、Spring2019!、10inchcock或类似的易于猜测/常见密码，那么您的所有努力都将徒劳无功。

我的建议是教育您的用户使用更强的密码/密码，并鼓励他们采用基本的密码卫生，而不是使用常见的模式，如季节，昵称，亲人，DoB等。

Answer 2

您的方法并不有用，因为您只考虑密码的长度，而不是考虑使密码强大的真正因素，这些因素是熵，而且可能还考虑到密码在泄漏或其他已知密码的数据库中还没有出现。因此，您的系统可能会认为correcthorsebatterystaple或1234567890足够长，但事实是，如果攻击者使用已知密码的字典或数据库，它们很可能很容易被破解。

但即使我们没有考虑到我刚才说的话，而且我们生活在一个理想的世界里，每个用户都只使用随机字符的密码，但主要问题是以下几点。考虑以下情况，其中最小接受长度是您的系统将接受的最小长度，理想的密码长度是您希望用户为获得安全密码而使用的长度。密码是随机字符串的字符，包括符号和一切(94个可能的字符)。

Minimum accepted lenght: 6 characters
Passwords to bruteforce: 94^6 = 6.9 x 10^11

Ideal password length: 12 characters
Passwords to bruteforce: 94^12 = 4.76 x 10^23

这意味着，平均来说，破解理想的密码将花费10^12倍于最短的可接受密码。如果您希望最短接受的密码(6个字符)与理想密码(12个字符)一样长，那么您必须每次尝试短密码的时间都要长10^12倍。

因此，如果您将理想密码(12个字符)的理想哈希时间设置为1秒，则必须将最小接受密码(6个字符)的哈希时间设置为10^12 seconds，该时间超过3万年。我担心用户不会愿意等上几千年。事实上，用户不会愿意等待超过几秒钟。因此，假设每次尝试最多需要3秒，获得最短的已接受密码。然后理想的密码将在3 / 10^12 = 3 picoseconds中进行散列。再说一次，这没有道理。

正如您所看到的，问题在于，在弱密码和足够强的密码之间，可以尝试的组合的数量会有巨大的差异，但另一方面，您或您的用户会发现可以接受的时间相对较短。

Answer 3

您建议的“密码长度潜在泄漏”的解决方案依赖于默默无闻。这是一个非常非常大的问题。If您的安全性取决于攻击者不知道您的实现是什么，它是不安全的。如果攻击者能够访问密码数据库，那么他们访问管理密码的后端代码也不是不合理的。攻击者也可以来自您的组织内部，他们会知道系统是如何工作的。知道密码的长度将极大地减少搜索空间，这对您试图保护的弱密码用户尤其不利。

下面是一些让攻击者更难破解密码的方法：

首先，不要用长度来衡量好的密码。使用密码强度检查工具(如兹克本 )。这将使您更容易地发现错误的密码做法。来自他们的GitHub：

zxcvbn是一个受密码破解器启发的密码强度估计器。通过模式匹配和保守估计，根据美国人口普查数据、维基百科和美国电视和电影中流行的英语单词以及日期、重复(aaa)、序列(abcd)、键盘模式(qwertyuiop)和l33t to等其他常见模式，对30k个常见密码、常见姓名和姓氏进行识别和权衡。

其次，如果可能的话，使用内存硬散列功能 (如Argon2 )。一般来说，对于攻击者来说，要扩展内存要比扩展计算周期要难得多。