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

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

因此，对读者而言，这篇文章最有意义的提示是 继续阅读 →

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

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

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

北京时间今天早上7:59:59，坚果云的所有Linux 操作系统 （CentOS 6.2)都出现CPU利用率暴涨的现象，主要影响的进程包括Java，MySQL等。直接重启Java和MySQL不能解决问题。后得知，该现象不仅发生在坚果云的服务器，很多互联网公司的服务器都在这一刻出现了不同程度的CPU利用率增长！

经过我们紧急的分析和调试，发现是因为操作系统内核在处理闰秒的时候，导致部分试图获取当前系统时间的进程出现Live Lock，也就是说，某个进程/线程在查询系统时间的时候，进入了一种类似死循环的状态，CPU利用率很高，同时不能完成时间查询。

我们猜测JVM和MySQL试图通过CPU硬件晶振的数据获得当前精确的时间，由于闰秒的关系，这个时间和操作系统维持的墙上时间（Wall Time，也就是显示给用户看的时间）不一致，导致了这个问题。

系统时间对于各种服务器程序尤为重要，例如在坚果云的系统中，很多节点都定期收集和报告系统状态，如果系统时间无法获取，可能导致部分节点被误判为故障，自动引起一系列不必要的故障恢复动作。

通过twitter, 邮件列表，论坛等其他媒体，我们发现很多互联网服务商都碰到类似问题，并且给出的方法多是重启服务器。坚果云团队戏称这是互联网全网统一重启服务器的日子。

与大家一样，我们首先选择的方式是按照顺序重启所有服务器，重新启动服务器确实能够解决这个问题。不过这个过程耗时长，而且容易出错。

幸运的是，谢谢Mozilla的一篇blog, 也谢谢Google快速灵活的实时索引，我们在重启服务器的过程中，发现了如下更简单的解决办法:

$ cat files/bin/leap-second.sh
# this is a quick-fix to the 6/30/12 leap second bug

if [ ! -f /tmp/leapsecond_2012_06_30 ]
then
/etc/init.d/ntpd stop; date `date +"%m%d%H%M%C%y.%S"` && /bin/touch /tmp/leapsecond_2012_06_30
fi

这个脚本只是简单的强制重置系统时间，从而让系统中所有时间回到同步的状态。完成后，你可以确认所有服务的状态回到正常，然后手动重启ntp服务。类似mozilla, 我们也使用puppet将该脚本在所有服务器上执行。

或许碰到问题的管理员都可以用这个办法解决。这是使用这个方法后的CPU利用率变化。

最后，希望航空航天，医疗等等重要系统不会受到这个问题的影响。在这些领域，重启系统很可能会造成巨大的伤害。

坚果云一直将”安全”做为最重要的目标之一. 不幸的是, “安全”二字标榜起来容易, 真要做到, 颇为艰难. 最近的一件工作就反映了这个情况.

百度对于大部分使用”https”访问的安全页面都不收录, 造成我们的主页迟迟不能出现在搜索引擎的首页结果上.  我们想了各种办法, 包括 “为百度爬虫指定单独的HTTP页面”, “通过百度的各个工具提交页面”,  “比对同类型网站的主页”, “咨询认识的百度的朋友”, 得出的结论是最好将主页制定为http版本, “见效快, 疗效好”, 同时主页打开的速度还够快.

不过我们仍在坚持使用https版本做为登录主页. 否则,  登录后的用户一旦直接在浏览器中输入”jianguoyun.com”,  用户身份信息(cookie)将直接明文传输. 如果用户处在不安全的网络环境, 例如咖啡店, 星巴克, 机场, 或者其他使用代理上网的场合,  只需一个简单工具, 用户数据将瞬间可以被其他人访问.

甭管用了什么本地加密, 也甭管用了多复杂的密码, 只要一个链条松动, 用户放在”云存储”中的数据将瞬间暴露. 这是做一个”安全云存储”困难的地方, 也是我们为什么将”安全”做为最重要的目标之一.

BTW: 有认识百度爬虫团队的人吗? 我们还在继续寻找解决办法.

在和用户交流的过程中,  发现大家对于数据隐私都比较关注.  更有趣的是,  越是对技术不感冒的用户,  越是关心数据会不会被别人偷窥.  当然, 也有国情的因素在里面.

说心里话,  就我个人而言,  特希望用户的数据在离开电脑的时候就进行高强度加密,  之后, 除了用户自己谁都不能解密.  这样所有隐私都能得以保护, 分享非法内容的可能性也几乎不存在. 只是用户一旦忘了密码,  事情就糟糕了；而且, 分享也很难进行.  应了那句老话,  “安全和便利”总是很难同时兼顾.

坚果铺子希望给用户提供个人使用的云存储空间,  而不仅仅用做共享.  因此, 隐私性也是我们经常思考的问题. 我们也在试图寻找安全和便利之间的平衡点. 这里的一些想法,  用于抛砖引玉, 想听听更多的建议.

安全是一个特别困难的问题, 因为:

1. 必须进行严格的端到端的控制, 任何一个环节出了问题,  安全就无从谈起
2. 懂得加密算法, 知道几个安全哈希函数,  未必就能设计出安全的协议和产品. 比如很多磁盘加密的产品,  都容易被反向工程破解
3. 阳光是最好的消毒剂,  封闭算法和实现并不是最好的保证安全的手段, 尤其是经验和能力比较缺乏的时候.  将产品中核心算法进行公开, 或许是保证安全的最佳途径
4. 数据的保护和隐私控制, 更难的是在程序和制度的管理.  人不是机器,  总是更容易犯下可以重现的错误

提到这里, 发现国内大部分的互联网服务,  不管是社交网络,  聊天, 或者云存储服务商,  似乎大多没有意识到端到端加密的意义.  更多的仅是在登录的时候, 只对用户名和密码进行保护.

殊不知, 用一个类似Firesheep这样的firefox插件,  任何人都可以在开放的WIFI网络中轻松劫持他人的账号,  访问他人数据, 甚至修改他人的密码.   中间过程的简单,  几乎不用进行任何培训.

越来越多用手机上网的我们, 是不是应该感到害怕?

或许, 我们应该站出来, 告诉国内的互联网服务商,  先保护我们在WIFI网络中的数据不会别他人窥探, 再来谈其他的数据保护问题吧.  配置一下服务器即可, 也不用花太多钱, 何乐而不为?

坚果铺子全部使用Https协议完成用户和服务器端之间的通信,  也是基于这个考虑. 虽然,  以我们有限的资源,  这会加大服务器的性能开销和影响页面的载入时间,  但是,  我们愿意以自己的努力, 唤醒大佬们的重视.

近两月来，快盘、新浪微盘、UC网盘、115网盘、腾讯微云等一系列网盘的业务调整公告在用户间引起轩然大波。面向个人的网盘市场在服务器成本不断增加，盈利模式模糊不清的情况下也将进入新一轮的转型探索期。在网盘关停的影响下，用户数据安放方式不外乎有以下几种： 继续阅读 →