http://sspai.com/31659/
前段时间，乌云曝光了网易邮箱存在的安全漏洞，尽管此事后来一波三折，网易一再否认，乌云也在漏洞页面上撤下了网易的名字，仅留下了「某邮箱」的字样，这其中的来来去去我们已经无从知晓细节，不过近来的确出现了非常多起以网易邮箱作为 iCloud 登录邮箱的用户，出现了 iPhone 被锁死的情况。
密码到底是如何泄露的？
想要知道密码是如何泄露的，不妨先想一想，你的密码都在哪？概括地来说，它只会在三个地方：本地、传输过程中、远程数据库中。
举个例子来说，如果你在浏览器中输入或保存了密码，这个密码在你点击登录前，只存在于你的本地，一旦你点击登录，浏览器就会将你的登录名和密码打包成为一个请求，发送给远程的服务器，这时候你的密码会经历一段非常短暂的旅程，最终到达远程服务器。如果你是第一次注册的话，你的密码还会以某种形式存储在对方的数据库中。
搞清楚了这个过程，我们来看一下各个环节里，都存在着哪些风险，会让你的密码泄露吧。
1. 本地泄露
1.1 恶意木马/恶意植入/键盘监听
电脑中病毒后，有些病毒只会在后台静悄悄地运行着，监控着你键盘上输入的每一个字符，然后偷偷发送给黑客。或者，前段时间的 XcodeGhost 事件，本质上也是应用程序中被植入了一段恶意代码，在后台偷偷地向远程服务器发送你的一些个人信息……
然而实际上，如果你能坚持使用可信任的设备，不安装未知来源的（盗版）软件，不对设备进行高危操作（如越狱、Root），感染恶意木马病毒的概率并不大。特别是在 iOS 系统上，得益于沙盒机制，每一个 App 的密码文件都单独加密保存，在不越狱的情况下，第三方是无法直接访问的。
建议：
- 不在公共或有潜在安全风险的设备上进行密码操作；
- 除非你非常有自信，否则请不越狱，不 Root；
- 不安装未知来源的（盗版）软件。
1.2 伪造
伪造在 Android 平台上特别常见，也出现过由于 URL Scheme 的无验证机制，而出现的伪造情况。很好理解，如果你开发一款和支付宝长得一模一样的 App，或者抢先占用 alipay:// 这个协议的 URL Scheme，理论上你可以诱骗或劫持用户打开你的伪造支付宝来进行资金安全操作，试想如果你没有任何安全知识，仅仅看着界面一模一样的伪造支付宝，你又如何保证自己不被钓鱼呢？
建议： 从可信的源（如 App Store、Google Play）下载安装软件。
2. 传输过程泄露
2.1 明文传输
你有没有想过，当你在一个网页上点击登录时，到底发生了什么？大多数情况下，浏览器其实是向服务器发送一个 POST 请求，这个请求可能是长这个样子的：http://login.qq.com/id=10001&pw=immahuateng。发现了吗？你的登录名和密码是直接暴露在这个 URL 里面的。
尽管有些网站会对这个链接进行所谓的加密处理，但有些所谓的加密是不可靠的，例如仅仅只是把这些字符串转化为 Base64 码，或者用 Javascript 进行加密处理，或许对于小白来说已经完全看不懂了，但是对于真正的黑客来说，这些加密都是可逆的，很多情况下完全可以不费吹灰之力恢复密码的本来面貌。
如果是在一个不可靠的网络环境下，黑客完全可以使用 Wireshark 这样的工具拦截请求包，直接看到你的密码。
建议：不使用不可信的 WiFi 网络，特别是公共场合的陌生、免费 WiFi。
2.2 非加密传输
实际上，由于成本的考量，很多国内网站的登录页面使用的仍然是 Http 协议，而在国外诸如 Facebook、Twitter 这样的网站，早已经全站强制 Https 协议。只是多了一个 s，两者有什么不同呢？后者的传输过程是加密的，这样即使像前一种情况下有人拦截了你的数据请求包，他也无法获知传输的到底是什么内容。
当然，近两年随着国内网络安全环境的提升，越来越多的网站开始支持甚至全站使用 Https 协议，不过，像网易邮箱等网站，SSL 仍然作为可选项存在，虽然开启后对速度会有一定影响，但相比起开启后的安全性能提升，这点速度影响微乎其微。
对了，前段时间闹得沸沸扬扬的 OpenSSL 漏洞事件，实际上就是说这种加密传输的实现方法有一个漏洞，正所谓没有绝对的安全，对浏览器和网站证书也可以保持适当的关注。
建议：
- 如果可能，使用 SSL 加密；
- 保持浏览器在最新版本；
- 检查网站证书是否可信（一般浏览器都会有提示）。
3. 服务器端泄露
就算你的本地计算机再安全，网络传输过程再可靠，然而一旦你使用的网络服务提供商不可靠，如果对方的数据库泄露（常称为拖库），那么你的密码安全一样岌岌可危。乍一看如果是对方的问题，好像自己也无能为力，不过一旦你了解到作为网络平台是如何存储用户密码的，那么还是能在密码设置方面为自己增加一些保障。
接下来的一些内容可能会有一些技术概念，不过我们为了方便大家的理解，尽可能地进行了简化处理，并加以例子说明。
3.1 明文泄露
什么是明文泄露呢？比如说你的密码是 123456，你所在的平台直接在它们的数据库里存下了你的密码 123456，是的，原封不动地存在数据库里。这意味着什么呢？对方的数据库一旦泄露，任何人，不需要借助任何技术手段，你的密码就直接展现在了他们面前。
听着好像很蠢，真的会有平台直接原封不动地把密码存下来吗？不要怀疑，想当年 2011 年轰动全网的 CSDN 泄露事件，作为一家技术网站，用户密码的保存就是用的原文。遇到这种事情，简直是叫天天不应，叫地地不灵。
建议：你选择不知道对方有多坑爹，直到……
3.2 可逆加密泄露
建议：如果说那些直接明文保存用户密码的公司很蠢，那么使用可逆加密的公司只是看起来不那么蠢而已。什么是可逆的加密呢？举一个很简单的例子，同样是保存用户的密码 123456，你可以设定一个规则，比如 1 对应 z，2 对应 y，3 对应 x，以此类推，那么最后存下来的密码就是 zyxwvu。发现了吗？可逆加密实际上是按照某个规则，加密后的密文与加密前的信息存在着一对一的关系。
由于可逆加密的这种可逆性，一旦数据库发生泄露，密码的暴露性实际上和明文差别不大，同样非常危险。
建议：对方可能以为自己不坑爹，实际也还是坑的……
3.3 不可逆加密泄露
相对于可逆加密，自然就有不可逆加密。你可能经常听说 MD5、SHA1、SHA256、SHA512、SHA-3 这些名字，实际上它们都是不可逆的哈希算法。
顾名思义，不可逆加密处理后，你无法通过加密后的密文直接反推出原密码，因为不存在一一对应的关系。这是如何实现的呢？比如说加密后的密文是 abcdefg，由于不对称性，生成这串密文的原密码可能是 123456，也可能是 woaisspai，它们经过哈希算法处理后的结果可能都是 abcdefg，这就保证了密文的不可逆性。
然而现实总是残酷的，即使是不可逆加密也并不是非常可靠。为什么这么说呢？由于任何人都可以模拟这些哈希算法，而现实生活中，又有许多用户的密码位数过短，或者设置的是同样的密码，这就会导致一个结果：即使经过加密后，很多数据库中存储的加密后的密文，由于它们对应的原密码是相同的，所以经过加密后生成的密文也是一样的。
甚至，黑客们专门制作了彩虹表。什么是彩虹表呢？就是预先模拟了一个数据库，这个数据库中穷尽了各种可能的密码组合，实际上就是一种暴力穷举的破解方法。黑客们可以将泄露的数据库中的加密值与预先准备好的彩虹表进行查找配对，一旦发现同样的密文，虽然不可逆加密的密文在理论上可能对应多个原始值，但由于有些密码的通用性，其反推的结果中，各个可能的原始值可能性却是不一样的。
而且这件事情并不难，举个例子来说，普通我们认为只要密码位数够长、组合够复杂、有大小写 + 数字 + 特殊符号总安全了吧？而事实情况是，一个由大小写字母 + 数字 + 部分特殊符号预先设立的彩虹表，穷举所有 14 位及以下的密码可能加密值时，整个彩虹表的大小也不过才 64GB，在当今的计算能力看来，进行暴力破解的成功机率还是非常大的。
建议：
- 密码位数不宜过短；
- 密码采用数字 + 大小写 + 特殊符号组成；
- 不要使用一些简单的、他人也可能使用的密码组合。
3.4 加盐后的不可逆加密泄露
如果不可逆加密都如此不可靠，还有没有什么解决方案呢？当然是有的，那就是加盐后的不可逆加密。什么是加盐呢？在理解这个概念前，让我们先回过头去看一下，为什么说不可逆加密依然不可靠。原因主要有两点：
- 同样的密码加密后生成的密文是一样的，而一些简单密码的使用频率很高；
- 由于计算能力的提升，使用暴力破解的成本越来越低，使得运用彩虹表进行暴力破解的成功概率上升。
要解决这两个问题，实际上需要解决的核心是，让加密后的密文与原密码进一步隔离，这就需要加盐了。例如最常用的组合 SHA512+SALT，这里的 SALT 就是我们所说的盐，当用户注册时，先进行一次不可逆加密后，再对生成的密文撒上一点盐，就是随机值，这个撒盐的过程可以是添加前后缀，可以是改变顺序，或者某种随机的规则，并在此加了盐的密文的基础上，再进行一次不可逆加密，就大功告成了。
举个例子来说，我们先把密码 123456 不可逆加密到 abcdefg，然后对生成的密文加一些盐，比如增加前后缀变成 xxxabcefgyyy，这时再对 xxxabcefgyyy 进行一次不可逆加密生成了二次密文 3kda3kd，这时候即使数据库泄露，黑客也很难通过之前的彩虹表或大数定理的情况，反推出用户的密码了。
建议：看来真正的安全，还是要靠厂商靠谱，基本上国内外的大厂的加密都会采用类似比这种方案更加复杂一些的方案。