内容简介:在前面两篇文章中,对用户口令进行加密的方式其实称为 Password-based encryption (PBE),算法实现很简单,那是不是有更好和更标准的 PBE 实现呢?基于 Hash+salt 的算法最大的问题在于 Hash 函数的运算太快了,虽然加盐让暴力攻击和彩虹表攻击的可行性大大减低,但现在攻击者能在非常快速的硬件(包括 GPU)上运行,如果那有没有更好的解决方案吗?如果让口令运算运算的慢一点,那么攻击者破解的速度也将上不去,这样是否就能更好的保护明文口令?
在前面两篇文章中,对用户口令进行加密的方式其实称为 Password-based encryption (PBE),算法实现很简单,那是不是有更好和更标准的 PBE 实现呢?
基于 Hash+salt 的算法最大的问题在于 Hash 函数的运算太快了,虽然加盐让暴力攻击和彩虹表攻击的可行性大大减低,但现在攻击者能在非常快速的硬件(包括 GPU)上运行,如果 时间足够 ,还是有很大几率完成暴力破解。
那有没有更好的解决方案吗?如果让口令运算运算的慢一点,那么攻击者破解的速度也将上不去,这样是否就能更好的保护明文口令?
在密码学中,key derivation function (KDF) 函数非常重要,它可以通过一个 master key(在 HTTPS 中用的非常多)、口令(password)、passphrase(密码学随机数生成器)生成一个或多个强壮的密钥,这些密钥本身被密码学算法使用(比如 AES、RSA 等等)。
用户的口令通过 PBF(前两篇文章讲解的算法实现)生成的口令密文不是密钥,所以最终结果不是用于密码学用途,是为了避免口令被破解,但本质上 BPF 算法也可以通过 KDF 函数实现,也就是利用 KDF 函数生成口令密文。
KDF 同样基于 Hash 函数,也有 salt 机制,当然最重要的是有 迭代因子 这个概念,有了迭代因子,会让处理速度变慢,减少爆破风险。
KDF 主要有三种实现,分别是 PBKDF2、bcrypt、scrypt ,这篇文章主要讨论 PBKDF2。
稍微休息下,希望大家理解上述概念之间的区别。
KDF 本质上属于 Key stretching、key strengthening,如果你了解 HTTPS,那么可能比较熟悉,比如在握手阶段,HTTPS 将 Premaster Secret 和客户端服务器端的随机数导出为 Master Secret,然后再将 Master Secret 导出为多个密钥块,这些密钥块包含 AES 的加密密钥或者初始化向量,用户后续通信数据的加密和完整性保护。
PBE 算法标准定义在 RFC 2898 文档中,大概的公式如下:
DK = PBKDF2(PRF, Password, Salt, c, dkLen)
-
PRF 是一个伪随机函数,可以简单的理解为 Hash 函数。
-
Password 表示口令 。
-
Salt 表示盐值,一个随机数。
-
c 表示迭代次数。
-
dkLen 表示最后输出的密钥长度。
如果 c 的数值越大,那么运算速度就越慢,增加了时间复杂度,攻击者破解的成功率就会下降。
使用 PHP 语言说明 PBKDF2 函数的使用:
$password = '明文口令'; // 随机的盐值 $salt = openssl_random_pseudo_bytes(12); $keyLength = 40; $iterations = 10000; $generated_key = openssl_pbkdf2($password, $salt, $keyLength, $iterations, 'sha256'); //转换为 16 进制 echo bin2hex($generated_key)."\n";
对这个过程循环2000次,总共需要 16秒 ,而如果运行简单的 Hash+salt,循环2000次,运行时间不到 0.1秒 。
从这个角度看,建议大家使用 PBKDF2 保护你的口令,但现在业界的保护口令的标准算法是 bcrypt ,下一篇文章会讲解。
口令保护系列文章:
可以了解我的书 《深入浅出HTTPS:从原理的实战》 ,如果你觉得还不错,还请在豆瓣上做个评论(地址:https://book.douban.com/subject/30250772/,或点击“原文连接”)。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- “黑客”必用兵器之“密码口令破解篇”
- 安全存储口令的业界标准:bcrypt 算法
- 使用wireshark分析ssh口令登录细节
- QQ安全中心 - 动态口令的生成算法
- Python实现FTP弱口令扫描器
- 从排查端口弱口令研究打造完美防御的思路
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。