是否有使用PBKDF2作为密码哈希的标准？

Question

加入我，打击弱密码哈希。

PBKDF2密码哈希应包含盐，迭代次数和哈希本身，以便以后进行验证。是否有标准格式，例如RFC2307的{SSHA}，适用于PBKDF2密码哈希？ BCRYPT很棒，但是PBKDF2更容易实现。

显然，没有规格。所以这是我的规格。

>>> from base64 import urlsafe_b64encode
>>> password = u"hashy the \N{SNOWMAN}"
>>> salt = urlsafe_b64decode('s8MHhEQ78sM=')
>>> encoded = pbkdf2_hash(password, salt=salt)
>>> encoded
'{PBKDF2}1000$s8MHhEQ78sM=$hcKhCiW13OVhmLrbagdY-RwJvkA='

更新： http://www.dlitz.net/software/python-pbkdf2/ 定义a crypt() 替代品。我更新了我的小规格以匹配他，除了他的开始 $p5k2$ 代替 {PBKDF2}. 。 （我需要从其他LDAP式{shemes}）迁移。

那是 {PBKDF2}, ，小写十六进制中的迭代次数， $, ， 这 urlsafe_base64 编码盐， $, ，和 urlsafe_base64 编码的PBKDF2输出。盐应为64位，迭代次数应至少为1000，并且具有HMAC-SHA1输出的PBKDF2可以是任何长度。在我的实现中，默认情况下总是20个字节（SHA-1哈希的长度）。

通过PBKDF2发送之前，必须将密码编码到UTF-8。没有关于是否应将其标准化为Unicode的NFC的消息。

该方案应按照 iterations 蛮力比{ssha}更为昂贵。

Answer 1

有针对 参数 PBKDF2的（盐和迭代），但不包括哈希。这包含在 PKCS＃5版本2.0 （请参阅附录A.2）。一些平台对编码和解码此ASN.1结构具有内置支持。

由于PBKDF2确实是一个密钥推导函数，因此指定一种将“哈希”捆绑（真正的派生键）与派生参数一起捆绑的方法是没有意义的秘密，永远不会存储。

但是，对于用作单向密码哈希的用法，可以将哈希作为参数存储在记录中，但可以存储在其自己的字段中。

Answer 2

我会和你一起打击弱小的哈希。

OWASP有密码存储备忘单（https://www.owasp.org/index.php/password_storage_cheat_sheet）一些指导；他们建议截至2012年至少64,000个PBKDF2迭代次数，每两年翻了一番（即2012年90,510）。

请注意，存储长长的密码随机盐始终是基本的。

请注意，具有广泛可变的每用件迭代次数并储存迭代次数以及盐的数量将为开裂软件增加一些复杂性，并可能有助于排除某些优化。例如，“鲍勃”被135817迭代加密，而“爱丽丝”使用95,121迭代，即2013年最少的（90510 + RAND（90510））。

还请注意，如果允许用户选择诸如“密码”，“ password1！”，“ P@$$ W0RD”和“ P@$$ W0RD123”之类的弱密码，所有这些都是无用的确实，基于规则的字典攻击确实很快（后者只是“密码”，具有以下规则：大写第一字母，1337-Speack，在末尾添加三位数号码）。获取基本的词典列表（phpbb，对于一个好的，小的启动词列表），然后将类似的规则应用于其中，您将在人们尝试“聪明”技巧的许多密码中破解很多密码。

因此，在检查新密码时，不要仅仅应用“上，下，数字，数字，至少11个字符的所有四个字符”，因为“ p@$$ W0RD123”符合这个看似非常艰难的规则。相反，使用该基本字典列表，看看基本规则是否会破解它（比实际尝试crack要简单得多 - 您可以降低列表和他们的单词，然后简单地编写代码，例如“如果最后4个字符是一个常见的一年，检查除了最后四个字符以外的所有字符外的所有字符”，“如果最后3个字符是数字，请检查除了最后3个字符以外的所有字符外的所有字符”和“检查所有除了对WordList的最后两个字符之外的所有字符”和“ de -1337密码 - 将 @变成a，3变成e，依此类推，然后对单词列表进行检查，并尝试其他规则。”

就密码而言，通常是一个好主意，尤其是如果其他一些字符被添加到单词中间，但是只有并且只有足够长的时间，因为您会放弃很多可能的组合。

请注意，即使在2012年，使用GPU的现代机器达到了数万次迭代（MD5，SHA1，SHA1，SHA-256，SHA-512等），甚至在2012年。键入密码，这充其量是一个非常适中的密码 - 只有4个所有较低的案例英语单词长度为7或以下的空格。因此，如果我们去寻找具有180亿个猜测的XKCD样式密码，请猜测第二个设置：现代的美国英语词典具有：长度为5或更小的21k单词长度为7或更少的36k单词长度为9或更少的46K单词长度11或更小的49k单词长13或更小

带有XKCD样式的密码，并且不愿意通过普及过滤单词（“正确”与“椅子”的“ vs.“ dmbsier” vs.“出血”）我们有21k^4，只有2e17的可能性。凭借180亿/秒的设置（如果我们面临单个SHA1迭代，一台具有8 GPU的机器），大约4个月来详尽地搜索键空间。如果我们有十个这样的设置，那大约是两个星期。如果我们排除了诸如“垃圾”之类的不太可能的单词，那么快速通过的速度要快得多。

现在，如果您从“巨大”的Linux American English WordList中获得单词，例如“ Balsamina”或“ Calvinistishist”（两者都使用“ go to to to Row”功能选择，那么我们将拥有30k的长度单词或长度为5或少115k单词长7或更少的231k单词长度9或更少317k的长度单词11或更少的362k单词长度13或更少

即使具有7个长度最大限制，该巨大的词典作为基础和随机选择的单词，我们有115k^4〜 = 1.8E20的可能性，或者如果设置保持最新状态，则大约12年）。这与13个字符非常相似，较低的情况 +只有数字密码。 “ 300年”是大多数估计会告诉您的，但他们没有考虑到摩尔的法律。