密码存储中MD5的安全问题与替代方案

gnehc 发布于2019-06-27 16:39 / 981人阅读

首发地址：我的个人博客，转载请注明出处。

md5安全吗？

经过各种安全事件后，很多系统在存放密码的时候不会直接存放明文密码了，大都改成了存放了 md5 加密（hash）后的密码，可是这样真的安全吗？

这儿有个脚本来测试下MD5的速度, 测试结果:

[root@f4d5945f1d7c tools]# php speed-of-md5.php
Array
(
    [rounds] => 100
    [times of a round] => 1000000
    [avg] => 0.23415904045105
    [max] => 0.28906106948853
    [min] => 0.21188998222351
)

有没有发现一个问题：MD5速度太快了，导致很容易进行暴力破解.

简单计算一下：

> Math.pow(10, 6) / 1000000 * 0.234
0.234
> Math.pow(36, 6) / 1000000 * 0.234 / 60
8.489451110400001
> Math.pow(62, 6) / 1000000 * 0.234 / 60 / 60
3.69201531296

使用6位纯数字密码，破解只要0.234秒！

使用6位数字+小写字母密码，破解只要8.49分钟！

使用6位数字+大小写混合字母密码，破解只要3.69个小时！

当然，使用长一点的密码会显著提高破解难度：

> Math.pow(10, 8) / 1000000 * 0.234
23.400000000000002
> Math.pow(36, 8) / 1000000 * 0.234 / 60 / 60 / 24
7.640505999359999
> Math.pow(62, 8) / 1000000 * 0.234 / 60 / 60 / 24 / 365
1.6201035231755982

使用8位纯数字密码，破解要23.4秒！

使用8位数字+小写字母密码，破解要7.64小时！

使用8位数字+大小写混合字母密码，破解要1.62年！

但是，别忘了，这个速度只是用PHP这个解释型语言在笔者的弱鸡个人电脑（i5-4460 CPU 3.20GHz）上跑出来的，还只是利用了一个线程一个CPU核心。若是放到最新的 Xeon E7 v4系列CPU的服务器上跑，充分利用其48个线程，并使用C语言来重写下测试代码，很容易就能提升个几百上千倍速度。那么即使用8位数字+大小写混合字母密码，破解也只要14小时！

更何况，很多人的密码都是采用比较有规律的字母或数字，更能降低暴力破解的难度... 如果没有加盐或加固定的盐，那么彩虹表破解就更easy了...

那么如何提升密码存储的安全性呢？bcrypt!

提升安全性就是提升密码的破解难度，至少让暴力破解难度提升到攻击者无法负担的地步。（当然用户密码的长度当然也很重要，建议至少8位，越长越安全）

这里不得不插播一句：PHP果然是世界上最好的语言 -- 标准库里面已经给出了解决方案。

PHP 5.5 的版本中加入了 password_xxx 系列函数, 而对之前的版本，也有兼容库可以用：password_compat.
在这个名叫“密码散列算法”的核心扩展中提供了一系列简洁明了的对密码存储封装的函数。简单介绍下：

password_hash 是对密码进行加密（hash），目前默认用（也只能用）bcrypt算法，相当于一个加强版的md5函数

password_verify 是一个验证密码的函数，内部采用的安全的字符串比较算法，可以预防基于时间的攻击, 相当于 $hashedPassword === md5($inputPassword)

password_needs_rehash 是判断是否需要升级的一个函数，这个函数厉害了，下面再来详细讲

password_hash 需要传入一个算法，现在默认和可以使用的都只有bcrypt算法，这个算法是怎么样的一个算法呢？为什么PHP标准库里面会选择bcrypt呢?

bcrypt是基于 Blowfish 算法的一种专门用于密码哈希的算法，由 Niels Provos 和 David Mazieres 设计的。这个算法的特别之处在于，别的算法都是追求快，这个算法中有一个至关重要的参数：cost. 正如其名，这个值越大，耗费的时间越长，而且是指数级增长 -- 其加密流程中有一部分是这样的：

EksBlowfishSetup(cost, salt, key)
    state <- InitState()
    state <- ExpandKey(state, salt, key)
    repeat (2^cost)                         // "^"表示指数关系
        state <- ExpandKey(state, 0, key)
        state <- ExpandKey(state, 0, salt)
    return state

比如下面是笔者的一次测试结果（个人弱机PC, i5-4460 CPU 3.20GHz）：

      cost       time
         8   0.021307
         9   0.037150
        10   0.079283
        11   0.175612
        12   0.317375
        13   0.663080
        14   1.330451
        15   2.245152
        16   4.291169
        17   8.318790
        18  16.472902
        19  35.146999

附：测试代码

这个速度与md5相比简直是蜗牛与猎豹的差别 -- 即使按照cost=8, 一个8位的大小写字母+数字的密码也要14万年才能暴力破解掉，更何况一般服务器都会至少设置为10或更大的值（那就需要54万年或更久了）。

显然，cost不是越大越好，越大的话会越占用服务器的CPU，反而容易引起DOS攻击。建议根据服务器的配置和业务的需求设置为10~12即可。最好同时对同一IP同一用户的登录尝试次数做限制，预防DOS攻击。

一个安全地存储密码的方案

总上所述，一个安全地存储密码的方案应该是这样子的：（直接放代码吧）

class User extends BaseModel
{
    const PASSWORD_COST = 11; // 这里配置bcrypt算法的代价，根据需要来随时升级
    const PASSWORD_ALGO = PASSWORD_BCRYPT; // 默认使用（现在也只能用）bcrypt

    /**
    * 验证密码是否正确
    *
    * @param string $plainPassword 用户密码的明文
    * @param bool  $autoRehash    是否自动重新计算下密码的hash值（如果有必要的话）
    * @return bool
    */
    public function verifyPassword($plainPassword, $autoRehash = true)
    {
        if (password_verify($plainPassword, $this->password)) {
            if ($autoRehash && password_needs_rehash($this->password, self::PASSWORD_ALGO, ["cost" => self::PASSWORD_COST])) {
                $this->updatePassword($plainPassword);
            }

            return true;
        }

        return false;
    }

    /**
    * 更新密码
    *
    * @param string $newPlainPassword
    */
    public function updatePassword($newPlainPassword)
    {
        $this->password = password_hash($newPlainPassword, self::PASSWORD_ALGO, ["cost" => self::PASSWORD_COST]);
        $this->save();
    }
}

这样子，在用户注册或修改密码的时候就调用 $user->updatePassword() 来设置密码，而登录的时候就调用 $user->verifyPassword() 来验证下密码是否正确。
当硬件性能提升到一定程度，而cost=11无法满足安全需求的时候，则修改下 PASSWORD_COST 的值即可无缝升级，让存放的密码更安全。

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/23048.html

当我们在谈论前端加密时，我们在谈些什么

摘要：所以我们今天只谈前端加密，一个部分人认为没有意义的工作。在中，认证过程使用了非对称加密算法，非认证过程中使用了对称加密算法。非对称加密上文中我们讨论了前端的哈希加密以及应用的场景。 showImg(https://segmentfault.com/img/bVAhTC); 当然在谈安全。前端安全是Web安全的一部分，常见的安全问题会有XSS、CSRF、SQL注入等，然而这些已经在程师...

wizChen 2019-08-01 15:36 评论0 收藏0
常用加密算法探寻

摘要：在开发过程中，常常用到各种加密方法和算法，本文总结了几种常用加密方法的原理。非对称加密原理非对称加密算法需要两个密钥公开密钥和私有密钥。在开发过程中，常常用到各种加密方法和算法，本文总结了几种常用加密方法的原理。对称加密 showImg(https://segmentfault.com/img/bVbacxw?w=1128&h=468); 原理：加密和解密数据使用同一个密钥，适...

Yu_Huang 2019-06-21 16:46 评论0 收藏0
md5/sha1+salt and Bcrypt

摘要：人们在微博上发表关于密码和安全相关的消息。该条微博的作者强烈建议使用进行加密。红色级别的安全隐患比黄色级别严重很多。防止黄色级别并不是硬性要求。当暴力破解失败，唯一的办法就是使用数据字典。在这种情况下，攻击者只需进行逐一计算。 PHP自带的MD5和SHA1加密函数是否安全，看了很多年前的一篇博文。原文为英文，个人英语能力真的有限，翻译了一下，其中必定存在很多错误，希望各位可以指正。原文...

史占广 2019-06-21 16:22 评论0 收藏0
md5/sha1+salt and Bcrypt

摘要：人们在微博上发表关于密码和安全相关的消息。该条微博的作者强烈建议使用进行加密。红色级别的安全隐患比黄色级别严重很多。防止黄色级别并不是硬性要求。当暴力破解失败，唯一的办法就是使用数据字典。在这种情况下，攻击者只需进行逐一计算。 PHP自带的MD5和SHA1加密函数是否安全，看了很多年前的一篇博文。原文为英文，个人英语能力真的有限，翻译了一下，其中必定存在很多错误，希望各位可以指正。原文...

yvonne 2019-06-27 10:35 评论0 收藏0
一种低成本的找回密码token验证方案

摘要：的特点主要有如下几个唯一性时效性不可预测很多大型业务中，比如说的找回密码流程中，对于发给用户的找回密码链接邮件需要同时提交用户输入的验证码和也就是该校验码对应的。随着互联网的高速发展，WEB2.0网站的业务越来越庞大，一些token验证在许多场景下都必不可少，比如说交易订单的防止多次提交，重要的敏感操作防止CSRF（跨站请求伪造）攻击，以及短信验证码，找回密码验证码，注册登录图形的生...

lakeside 2019-06-27 14:05 评论0 收藏0