注册登录原理及密码安全问题

安全性，是一个公司生死存亡的关键，华为、腾讯和阿里等公司，都有大量的技术人员来保障业务安全。平时工作中，一旦遇到安全问题，必须立即高优先级处理。安全攻防，是一个动态的博弈，没有攻不破的防守，也没有防不住的进攻。
注册APP成功后，就可以登录。看似简单的操作，其实蕴含了很多密码安全的问题。

当你注册APP，填写用户名和密码，点击提交后， APP后台肯定需要“存储你的用户名和密码”，而当你输入用户名和密码进行登录时，APP后台就能判定你输入的用户名和密码与当时注册的用户名和密码是否匹配，从而确定是否让你登录。
那么，有没有思考过这个问题：APP后台开发的程序员GG们，能偷窥到你的密码吗？他们会盗用你的账号和密码进行登录吗？黑客攻击APP后台后，能盗用你的账号和密码吗？
显然，这是不能允许的。没有办法在道德和法律的规范下严格禁止这样的行为，那就要从技术机制上禁止，要确保即使在数据库和程序代码被盗走的情况下，坏人也无法破解密码。

密码直接明文存储

如果在APP后台数据库中直接存储用户名和密码，那么黑客可就要在睡梦中笑醒了：

当年CSDN真是搞笑搬地存在：

密码加密存储

自然地，我们想到对密码进行加密存储：

这种方式也挺业余的，既然能加密，就有办法解密，同样存在密码被盗的风险，如果APP后台能以某种方式还原密码，那肯定就是流氓系统。我们也有这样一个常识：当用户忘记密码后，正确做法不是APP后台告诉用户密码是多少(因为APP后台压根就不应该知道用户的密码)，而应该让用户重新设置密码。

密码直接哈希存储

哈希函数，单向散列，且几乎不冲突，故可以考虑对密码进行哈希变换后存储，如下：

如此一来，从理论上讲，即使哈希值yyyyyy被盗走，别人也难以还原成原来的abcd123了，因为哈希函数不可逆。这样貌似就实现了密码的安全存储，不过，有点太天真了。

如果数据库和程序代码被盗，从理论上讲，难以用yyyyyy反推出密码abcd123, 但黑客可以用彩虹表攻击，分分钟就能破解出密码abcd123, 彩虹表攻击的图示如下：

密码多次哈希后存储

有的朋友可能觉得彩虹表能实现攻击，主要是因为只用一次哈希，那么多加几次哈希，是不是就解决问题了呢？

显然不是。多次哈希后，一旦黑客拿到你多次哈希的程序代码和数据库，便可以构造多重彩虹表，分分钟破解密码:

固定盐值的哈希存储(无需存盐)

思考一下，现在的问题是，要抗彩虹表攻击，可以考虑这么做：

P = hash(user + hash(password)) 

此处的user就是用户名，用作盐值。这样，就增加了黑客的破解难度，因为黑客需要针对每个user做一张特定的二重彩虹表，才有可能破解。

即便如此，在攻击一些重要user时， 黑客可能感觉值得尝试一下，所以，用固定盐还是存在较大风险。

随机盐值的哈希存储(需要存盐)

既然固定盐值不好，那就用随机盐吧，于是可以考虑这么做：

P = hash(salt + hash(password)) 

这个随机盐salt，需要存储在APP后台数据库中。可问题是，APP和APP后台需要使用相同的随机盐，那么APP是怎样获取APP后台的随机盐呢？这又涉及到一系列的加密算法(RSA和AES)和秘钥管理问题，在实际系统中，有些公司就是这么做的。

随机盐的引入，可以让彩虹表失效，黑客只能“望盐兴叹”。

bcrypt存储(无需存盐)

有没有更简洁且安全的做法呢？有的，用bcrypt吧。我始终觉得，bcrypt这个名字不太好，应该叫bSHA, 其实也不用纠结名字。bcrypt是一个带随机盐的哈希函数，在哈希值中，又携带了盐的信息，所以，在APP后台，就能从哈希值中解析出APP端使用的随机盐，所以，该随机盐不需要被APP后台数据库存储。使用bcrypt后，注册登录逻辑图如下：

而且，bcrypt是一个相对较慢的哈希函数(比如设置1s)，这就大大增加了黑客暴力破解的难度。这里要说明的是，APP端的bcrypt慢，但APP后台对应校验函数并不慢，所以不会影响APP后台服务的性能。

扫码登录原理

实际上，用户在APP上登录后，会获取一个登录态票据(session key, 一般简写为skey)，在后续的每次操作中，用户不必再输入密码了，APP自动携带登录态票据，此时APP后台进行登录态票据校验就可以了，也提升了便利性和安全性。

扫码登录的原理：

用户登录APP后，获取到了登录态票据skey, 然后用户利用APP对网页上的二维码进行扫描，获取隐藏在二维码中的token, 并提交到后台，实现扫码登录，扫码登录的逻辑图如下：

这个图一目了然，不需要具体解释每一步。值得注意的是，步骤6执行完后，步骤3中的轮询才会知道网页token和APP端的userID/skey在后台建立了关联，此时网页的扫码登录也就成功了。