被脱裤也不怕 - 反馈总结

在发出前两篇安全相关的文章（设计安全的账号系统的正确姿势 ，即使被拖库，也可以保证密码不泄露）后，我陆续收到了不少的反馈。我的文章本意是引起大家对密码安全的重视，给大家设计账号安全系统时提供一些参考和思路。

正如张小龙说的，“我所说的一切都是错的”。

所以，我更希望大家从辩证的角度去看待前两篇文章，然后结合自身项目的情况去做相应的设计。同时，我收到不少有价值的反馈，我觉得有必要将这些反馈整理一下，给大家一些参考，也算是对前面文章的补充。

上篇文章没有提到 HTTPS（SSL/TLS），是我疏漏了。作为一个安全的系统，在保证传输安全时强烈建议直接上 HTTPS（SSL/TLS）。文章中使用 ECDH 交换密钥传输的过程其实和 HTTPS（SSL/TLS）是类似的，只不过 HTTPS（SSL/TLS）实现的要完善太多。

正如一位朋友反馈所说：“14年的时候 openssl 爆出过一个名为 Heartbleed 的漏洞，可见良好的算法不一定被良好的实现，所以从开发者的角度还是不要觉得存在绝对安全的算法比较好。” 所以可以认为我的方案是在 HTTPS（SSL/TLS）基础上再一层加固，当然，如果你认为这一层加固没必要也可以去掉。

另一方面，目前大量网站还在使用 HTTP ，很多游戏设计时也并未使用 TLS ，所以，我上篇文章使用的方法还是有一定的意义的。

反馈汇总

1. “应该从源头上禁止用户使用简单密码”

   回复：非常同意！

2. “获取 salt 并不需要啥验证，那么还有必要分开存储么，脱裤者直接根据uid调一遍接口不就拿到了？相当于就是公开的吧？”

   回复：确实是这样。salt 相当于公开的了，没有必要分开存储了。如果你有更好的方法，请告诉我。

3. “使用 HTTPS(SSL/TLS) 来保障传输的安全是不是就可以了？”

   回复：理论上是足够了，而且推荐使用。 如果你的项目安全级别非常高，本着不信任绝对安全的角度可考虑再一层加固。

4. “salt 使用密码学安全的随机数生成就够了，不需要使用 uid 。”

   回复：同意，确实不是很必要。

5. “服务器性能够强劲，bcrypt 放在服务端执行也没什么问题。”

   回复：通过调整 bcrypt 参数让服务端执行在可接受的时间范围内确实可以。但是把这种耗时的操作放到客户端去做不是更好吗？

6. “不知攻焉知防，还是使用现有的算法和协议比较好，不要自己发明。即使自己发明，也需要经过实践的检验不断迭代才行。”

   回复：首先，文中用到的都是现有的成熟算法，如 bcrypt，SHA-512， AES ，包括 ECDH，并没有重新发明什么。文章重点是对密码的两次加盐哈希以及密码的验证方式。当然，方案需要在实践中不断迭代优化，我也是不能同意再多。

有一位朋友说的非常好，很多互联网公司对安全不重视，近年来密码安全事故频繁发生，导致密码泄露后被拿去撞库，用户利益受损。应该去推动一下密码安全的业界标准，避免企业犯错用户买单。同时，互联网没有绝对的安全，强烈建议用户不要用同一个密码，密码定期改！

好了，我所说的也都是错的。欢迎继续交流。