MD5是一种常用的单向哈希算法。它被广泛用于以下几个用途:
- 检查数据是否一致。将两地存储的数据进行哈希,比较结果,如果结果一致就无需再进行数据比对。这是利用了其“抵抗冲突”(collision- resistant)的能力,两个不同的数据,其哈希值只有很小的几率一致。相当多数据服务,尤其是网盘服务,利用类似的做法来检测重复数据,避免重复上传。
- 存储用户密码。将密码哈希后的结果存储在数据库中,以做密码匹配。这是利用了其做为单向哈希的特点,从计算后的哈希值不能得到密码。
- 校验数据正确性。将数据和数据哈希后的结果一并传输,用于检验传输过程中数据是否有损坏。这是利用了很难找到两个不同的数据,其哈希结果一致的特点。
下面我们将说明为什么对于上面三种用途, 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,导致接收方仍然认为数据是正确的。
补充:我们在另外一篇文章里面讲述了应对这些问题的方法。
Pingback引用通告: 坚果云:小团队缔造大云存储 | 科技推
Pingback引用通告: 坚果云:小团队缔造大云存储 - 阅趣-阅读的乐趣
泛泛而谈
Pingback引用通告: Definite Digest » 坚果云:小团队缔造大云存储
Pingback引用通告: 坚果云:小团队缔造大云存储 | IT & 数码
Pingback引用通告: 坚果云:小团队缔造大云存储 - App-Goog-les
Pingback引用通告: Google Reader分享 » 坚果云:小团队缔造大云存储
Pingback引用通告: 坚果云:小团队缔造的云存储服务 | 吃杂烩
Pingback引用通告: 为什么应该放弃或减少使用MD5 – VOICENS
MD5本身就是一种不可逆的签名算法,说白了算是种有损的压缩吧,针对第一点你可以换一个位数更长的签名算法,每二点,你可以更改算法本身,读一下MD5的论文,挺简单的,第三种,如果安全性要求高直接换成SSH或IPSEC
第三点的指的是MD5 Length Extension Attack吧?其实还是可以用,但要变个用法:http://hi.baidu.com/aullik5/item/a4906012f04552fc9c778afa
用简洁的博文说了一下众所周知的问题,但却没有谈论更好的解决方案 🙁
要切实可行的,不要理论化的
楼主说的有道理,能给个详细的解决方案吗?比如说就以楼主说的三个例子,我们用什么方式可以解决这些问题?
我们已经更新了文章, http://blog.jianguoyun.com/?p=537
Pingback引用通告: 为什么应该放弃或减少使用MD5【续】 | 坚果云博客
我觉得博主提出的说法有不少问题。
1:检查数据是否一致。不管你使用SHA-512还是NIST即将公布的SHA-3,对于任何HASH算法都存在碰撞问题,这不是MD5特有的问题。唯一的问题是MD5有可能被用户故意制造碰撞,不过我没看出这么做有什么意义。对于网盘来说,可以随机向客户端询问文件片段,然后判断是否和服务器端一致。
2:存储用户密码。虽然博主说得没错,不过明明有bcrypt这种专门用来存储密码的方案,难道还会有人要自己山寨搞MD5来散列吗?MD5设计就不是用来散列密码的,事实上MD5尽可能的优化了其计算速度,这与存储密码的要求正好相反。
3:校验数据正确性。我觉得这个就该用MD5或CRC32做,因为效率问题。为了罕见的冲撞而使用SHA-512算法毫无必要。事实上,用于消息认证的HMAC算法就可以使用MD5作为后端(可参见RFC 2104)。虽然博主提到,针对数据篡改的攻击的确应该避免使用MD5,但数据篡改和传输错误本来就有本质的区别,一个是人为故意制造的,另一个是物理上的随机噪声产生的。
楼主在劝导别人放弃MD5使用的同时,是不是应该发表一下该用什么来替代,sha1? des? 纯粹吐槽缺点是毫无意义的,说的缺点都是众所周知,毫无新意,我心中的坚果云博客不是这个样子的。
恕在下冒犯,惟此文之見不敢苟同。
針對是第一種和第三種。如果不存在有人精心設計資料讓他們的MD5相同,有意義的自然資料碰撞之概率微乎其微,如果在加上長度校驗,基本上可以保證使用。而且轉而使用更加高級之演算法代價也是顯而易見的。另外,即使我不說想必作者也明白即使使用更加高級之演算法,仍然有碰撞之可能性,唯一可以保證萬無一失之方法是直接檢查二進制資料,但這樣代價實在太高。而且通訊協議中使用的32位CRC明顯比MD5更加脆弱,但是這麼脆弱的演算法決不是為了保護免遭惡意攻擊者攻擊,那時上層應用之事情,而且也不是所有的連接都那麼敏感需要防止攻擊。
密碼保存則不同,因為密碼之目的,就是為了對抗惡意之攻擊者。因此MD5才會被更加安全的演算法替代。
是的,完全避免碰撞是不可能的。
CRC32使用来校验数据完整性的,它是一个best effort的工作模式,md5单纯用来校验数据是否有bit error当然是可以的,但是它不能用于防范Byzantine Fault.
不过利用更高强度的算法,加上challenge response的方式,可以极大的降低这个风险。
通过这样即可: http://www.zhihu.com/question/20489900?nr=1¬i_id=27726818#1235857
文中给出的两个数据没有测试成功(不清楚是否包含空格换行等,试了几次都和文中的md5不一样)
需要用16进制的方式进行校验。
我就在用, 那么请问用什么来代替呢?
参考这篇文章。
http://www.zhihu.com/question/20489900?nr=1¬i_id=27726818#1235857
Pingback引用通告: 坚果云招聘内容编辑 | 坚果云博客