今天，我来聊注册和登录的原理，主要讨论安全问题。安全是一个公司生死存亡的关键， 华为 和 腾讯 都有大量的技术人员，来保障业务的安全。

在工作中，一旦遇到了安全问题，必须立即处理，谁都担不起安全责任。安全攻防是一个动态博弈，没有攻不破的防守，也没有防不住的进攻。

而且，在面试中，安全问题也是必然会涉及到的，比如最基本的AES、 RSA 、 TLS 、 HTTPS 、注册登录、密码存储等知识，我们必须熟悉。

注册APP时，你填写用户名和密码，点击提交后，APP后台肯定需要 “存储你的用户名和密码” ，为后面的登录验证做准备。

登录APP时，你输入用户名和密码，APP后台就能验证你输入的用户名和密码，与当时注册APP时的用户名和密码是否匹配。

那么，有没有思考过这个问题： APP后台开发的程序员GG们，能偷窥到你的密码吗？他们会盗用你的账号和密码进行登录吗？黑客攻击APP后台后，能盗用你的账号和密码吗？

显然，这是不允许的。没有办法在道德和法律的规范下严格禁止这样的行为，那就要从技术机制上禁止，要确保即使在数据库和程序代码被盗走的情况下，坏人也无法破解密码。

一. 密码直接明文存储

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

那么，有没有网站中招呢？当然有！当年CSDN博客首当其冲，当时的声明如下：

二. 密码加密存储

自然地，我们想到对密码进行加密存储。不过，这种方式也挺业余的，既然能加密，就有办法解密，同样存在密码被盗的风险，如果APP后台能以某种方式还原密码，那就是流氓系统哈。

我们有这样一个常识：当用户忘记密码后，正确做法不是APP后台告诉用户密码是多少(因为APP后台压根就不应该知道用户的密码)，而应该让用户重新设置密码。回想一下，是不是如此？

三. 密码哈希存储

哈希函数，单向散列，且几乎不冲突，故可以考虑对密码进行哈希变换后存储。从理论上讲，即使哈希值yyyyyy被盗走，别人也难以还原成原来的abcd123了，因为哈希函数不可逆。这样貌似就实现了密码的安全存储，不过，有点太天真了。

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

我来简单解释一下：

黑客对一些常用密码进行哈希，形成一张很大的资料表，一旦黑客盗走数据库中的密码哈希值yyyyyy, 就可以在资料表中进行查找，很快能知道密码是abcd123.

这个资料表，就是所谓的彩虹表。理论上不可反解的哈希函数，被狡猾的黑客给“破解”了，并且得到了密码。所以，直接用哈希的方式存储密码，是肯定不行的。

四. 密码多次哈希存储

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

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

五. 固定盐值哈希存储

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

 P = hash(user + hash(password))   

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

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

六. 随机盐值哈希存储

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

 P = hash(salt + hash(password))   

这个随机盐salt，需要存储在APP后台数据库中。可问题是，APP和APP后台需要使用相同的随机盐，那么APP是怎样获取APP后台的随机盐呢？

这又涉及到一系列的加密算法和秘钥管理问题，在实际系统中，有些公司就是这么做的。随机盐的引入，可以让彩虹表失效，黑客只能“望盐兴叹”。

七. bcrypt 存储

有没有更简洁且安全的做法呢？有！用bcrypt吧。我觉得，bcrypt这个名字不太好，应该叫bSHA，bcrypt是一个带随机盐的哈希函数，在哈希值中，又携带了盐的信息。

所以，在APP后台，就能从哈希值中解析出APP端使用的随机盐值，该随机盐不需要被APP后台数据库存储，减少了盐值泄露的风险。使用bcrypt后，注册登录的逻辑图如下：

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

八. 扫码登录原理

在本文的最后一部分，我们来聊一下 扫码登录 的原理。回想一下，扫码登录是不是到处可见呢？那么，扫码登录的逻辑和流程是怎样的呢？别着急，我们一起来看看这个有趣有用的问题。

用户登录APP后，会获取登录态票据(session key, 简写为skey)，在后续操作中，不必再输入密码，APP自动携带登录态票据，此时APP后台进行登录态票据校验即可，提升了便利性。

用户登录APP后，获取到了登录态票据skey, 然后用户利用APP对网页上的二维码进行扫描，获取隐藏在二维码中的token，并把token提交到后台，下图一目了然，无需具体解释每一步。

值得注意的是，步骤6执行完后，步骤3中的 轮询 才会知道网页token和APP端的userID/skey在后台建立了关联，此时扫码登录成功。我曾经也设计了一个扫码登录方案，思路上大同小异。

好的，本文先聊到这里了，相信大家对注册登录中的安全问题有了更深入的理解。愿工作顺利，面试也顺利。 今天先这样，咱们明天见 。

本人花费2个月时间，整理了一套 java 开发技术资料，内容涵盖java基础，分布式、微服务等主流技术资料，包含大厂面经，学习笔记、源码讲义、项目实战、讲解视频。

希望可以帮助一些想通过自学提升能力的朋友，领取资料，扫码关注一下

记得转发+关注+私信

私信回复【2022学习资料】

领取更多学习资料