为什么应该放弃或减少使用MD5

MD5是一种常用的单向哈希算法。它被广泛用于以下几个用途:

  1. 检查数据是否一致。将两地存储的数据进行哈希,比较结果,如果结果一致就无需再进行数据比对。这是利用了其“抵抗冲突”(collision- resistant)的能力,两个不同的数据,其哈希值只有很小的几率一致。相当多数据服务,尤其是网盘服务,利用类似的做法来检测重复数据,避免重复上传。
  2. 存储用户密码。将密码哈希后的结果存储在数据库中,以做密码匹配。这是利用了其做为单向哈希的特点,从计算后的哈希值不能得到密码。
  3. 校验数据正确性。将数据和数据哈希后的结果一并传输,用于检验传输过程中数据是否有损坏。这是利用了很难找到两个不同的数据,其哈希结果一致的特点。

下面我们将说明为什么对于上面三种用途, MD5都不适用。

第一个用途尤其可怕。这个用途的最大的问题是,MD5在现实中已经被发现有相当多的数据都可能导致冲突。举例而言,如下两段数据的MD5哈希值就是完全一样的。

                   数据 1  

    4d c9 68 ff 0e e3 5c 20 95 72 d4 77 7b 72 15 87
    d3 6f a7 b2 1b dc 56 b7 4a 3d c0 78 3e 7b 95 18
    af bf a2 00 a8 28 4b f3 6e 8e 4b 55 b3 5f 42 75
    93 d8 49 67 6d a0 d1 55 5d 83 60 fb 5f 07 fe a2

                   数据 2

    4d c9 68 ff 0e e3 5c 20 95 72 d4 77 7b 72 15 87
    d3 6f a7 b2 1b dc 56 b7 4a 3d c0 78 3e 7b 95 18
    af bf a2 02 a8 28 4b f3 6e 8e 4b 55 b3 5f 42 75
    93 d8 49 67 6d a0 d1 d5 5d 83 60 fb 5f 07 fe a2

                 输出相同的MD5 哈希

           008ee33a9d58b51cfeb425b0959121c9

这意味着,如果用户提供数据 1,服务器已经存储数据 2。通过简单的MD5哈希方式检查重复,服务器上为用户保存的数据就是2。 接下来发生的事情大家都知道了,就是用户数据丢了!

第二个用途很容易遭到rainbow table攻击,和明文存储密码的实质区别不大。更详细的分析可以察看这篇文章

第三个用途里一般会在需要哈希的数据中混入某些秘密,也就是计算公式为md5(secret key + data)。 但这样并不适合用于验证数据的完整性。这是因为,从理论上上来说,如果知道md5(secret key +X),即使不知道secret key的内容, 仍然可能通过对X的分析,计算得到md5(secret key +Y),从而将X成功的替换成Y,导致接收方仍然认为数据是正确的。

补充:我们在另外一篇文章里面讲述了应对这些问题的方法。

    分享到:
此条目发表在 技术分享 分类目录。将固定链接加入收藏夹。

为什么应该放弃或减少使用MD5》有 26 条评论

  1. [...] ifanr:你们官方博客上写了不少关于数据安全的文章,比如这篇《为什么应该放弃或减少使用 MD5》,比较偏技术性,可以通俗地介绍下么? [...]

  2. [...] ifanr:你们官方博客上写了不少关于数据安全的文章,比如这篇《为什么应该放弃或减少使用 MD5》,比较偏技术性,可以通俗地介绍下么? [...]

  3. [...] ifanr:你们官方博客上写了不少关于数据安全的文章,比如这篇《为什么应该放弃或减少使用 MD5》,比较偏技术性,可以通俗地介绍下么? [...]

  4. [...] ifanr:你们官方博客上写了不少关于数据安全的文章,比如这篇《为什么应该放弃或减少使用 MD5》,比较偏技术性,可以通俗地介绍下么? [...]

  5. [...] ifanr:你们官方博客上写了不少关于数据安全的文章,比如这篇《为什么应该放弃或减少使用 MD5》,比较偏技术性,可以通俗地介绍下么? [...]

  6. [...] ifanr:你们官方博客上写了不少关于数据安全的文章,比如这篇《为什么应该放弃或减少使用 MD5》,比较偏技术性,可以通俗地介绍下么? [...]

  7. [...] ifanr:你们官方博客上写了不少关于数据安全的文章,比如这篇《为什么应该放弃或减少使用 MD5》,比较偏技术性,可以通俗地介绍下么? [...]

  8. [...] 前面一篇文章讲述了为什么应该放弃或减少使用MD5,意料之外的是,线上线下都有不少读者表示希望知道更多信息。也有一些专家级读者指出了文章中的一些不足和不够详细的地方。希望能在这篇文章中一并补充,如有错误,也烦请指正。 [...]

  9. frog 说:

    MD5本身就是一种不可逆的签名算法,说白了算是种有损的压缩吧,针对第一点你可以换一个位数更长的签名算法,每二点,你可以更改算法本身,读一下MD5的论文,挺简单的,第三种,如果安全性要求高直接换成SSH或IPSEC

  10. hl 说:

    第三点的指的是MD5 Length Extension Attack吧?其实还是可以用,但要变个用法:http://hi.baidu.com/aullik5/item/a4906012f04552fc9c778afa

  11. 候鸟过海 说:

    用简洁的博文说了一下众所周知的问题,但却没有谈论更好的解决方案 :(

  12. 勇_微博 说:

    要切实可行的,不要理论化的

  13. 勇_微博 说:

    楼主说的有道理,能给个详细的解决方案吗?比如说就以楼主说的三个例子,我们用什么方式可以解决这些问题?

  14. [...] 前面一篇文章讲述了为什么应该放弃或减少使用MD5,意料之外的是,线上线下都有不少朋友表示希望知道更多信息。也有一些专家级读者指出了文章中的一些不足和不够详细的地方。希望能在这篇文章中一并补充,如果错误,也烦请指正。 [...]

  15. mizuchi 说:

    我觉得博主提出的说法有不少问题。
    1:检查数据是否一致。不管你使用SHA-512还是NIST即将公布的SHA-3,对于任何HASH算法都存在碰撞问题,这不是MD5特有的问题。唯一的问题是MD5有可能被用户故意制造碰撞,不过我没看出这么做有什么意义。对于网盘来说,可以随机向客户端询问文件片段,然后判断是否和服务器端一致。
    2:存储用户密码。虽然博主说得没错,不过明明有bcrypt这种专门用来存储密码的方案,难道还会有人要自己山寨搞MD5来散列吗?MD5设计就不是用来散列密码的,事实上MD5尽可能的优化了其计算速度,这与存储密码的要求正好相反。
    3:校验数据正确性。我觉得这个就该用MD5或CRC32做,因为效率问题。为了罕见的冲撞而使用SHA-512算法毫无必要。事实上,用于消息认证的HMAC算法就可以使用MD5作为后端(可参见RFC 2104)。虽然博主提到,针对数据篡改的攻击的确应该避免使用MD5,但数据篡改和传输错误本来就有本质的区别,一个是人为故意制造的,另一个是物理上的随机噪声产生的。

  16. 金马 说:

    楼主在劝导别人放弃MD5使用的同时,是不是应该发表一下该用什么来替代,sha1? des? 纯粹吐槽缺点是毫无意义的,说的缺点都是众所周知,毫无新意,我心中的坚果云博客不是这个样子的。

  17. Cosmia 说:

    恕在下冒犯,惟此文之見不敢苟同。
    針對是第一種和第三種。如果不存在有人精心設計資料讓他們的MD5相同,有意義的自然資料碰撞之概率微乎其微,如果在加上長度校驗,基本上可以保證使用。而且轉而使用更加高級之演算法代價也是顯而易見的。另外,即使我不說想必作者也明白即使使用更加高級之演算法,仍然有碰撞之可能性,唯一可以保證萬無一失之方法是直接檢查二進制資料,但這樣代價實在太高。而且通訊協議中使用的32位CRC明顯比MD5更加脆弱,但是這麼脆弱的演算法決不是為了保護免遭惡意攻擊者攻擊,那時上層應用之事情,而且也不是所有的連接都那麼敏感需要防止攻擊。

    密碼保存則不同,因為密碼之目的,就是為了對抗惡意之攻擊者。因此MD5才會被更加安全的演算法替代。

  18. chyanog 说:

    文中给出的两个数据没有测试成功(不清楚是否包含空格换行等,试了几次都和文中的md5不一样)

  19. tcdona 说:

    我就在用, 那么请问用什么来代替呢?

  20. [...] 官方微博 ← 为什么应该放弃或减少使用MD5 [...]