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

首先，原文是说MD5算法在很多场合都不再安全，应该避免使用，并不是全面否定其他安全哈希算法。SHA-2系列算法在最近几年应该还是足够安全和可靠的。另外，按照计划，SHA-3系列的哈希算法也即将在近期公开发布。

因此，对读者而言，这篇文章最有意义的提示是：“在使用安全哈希算法时，考虑使用SHA-2系列算法乃至更高级别算法，而不是MD5“。

MD5最大的问题在于，通过我国的王晓云教授等学者的工作，md5已经被证明可以进行碰撞攻击。也就是说，攻击者可以产生两个应用程序，内容不一样，但是哈希值完全一样。

在云存储的应用场合中，这种危害表现为攻击者可以伪造一个Windows 的安装光盘，在其中嵌入木马，通过上述手段让MD5哈希值和微软官方发布的光盘签名一致，抢先上传到分享类网盘中。如果该网盘采用MD5检查重复文件（例如离线下载服务）， 木马就会被植入到希望下载原版光盘用户的电脑中。

这种攻击形式不是天方夜谈，根据微软官方的报告，一款名为Flame的木马就用了类似的手段。当然，这种方式目前还是非常高级的攻击手段。

另外，实际应用中我们也常需要验证对方发送的数据没有经过任何攻击者篡改。 例如，微博的API（应用接口）服务就需要验证请求来自于一个合法的授权方，而不是一个借用第三方名义的攻击者。

使用私钥加密，公钥解密验证的方式是完全可行的，但是因为非对称加密算法执行效率低下。因此，很多时候会用类似MD5的哈希算法验证哈希值和内容一致来保证数据未被篡改。

从前一篇文章的描述可以看出，MD5在这种场景是不安全的，不过需要额外注意的是，即使SHA-2系列的算法用于这个场景也是不安全的，这个时候应该考虑使用HMAC系列的对称验证算法。这个问题的根源是，从理论上上来说，如果知道hash(secret key +X)，即使不知道secret key的内容, 仍然可能通过对X的分析，计算得到hash(secret key +Y），从而将X成功的替换成Y，导致接收误以为Y就是X。而HMAC尽管基于安全哈希算法，却能避免这个类型的攻击。

从开放API的实例来看，Flickr的API在早期犯过这个错误。

当然，如果用于验证通信中的数据是否因为信道干扰损坏（而非攻击者人为干扰），或者将数据进行足够均匀的分布，MD5还是完全称职的，甚至是优秀的。关于这方面的内容，如果读者有兴趣，欢迎通过微博或者评论反馈，我们也可以再行补充。