用户注册登录系统加密方案分析与实践

对于一个网站而言，用户注册登录系统的重要性不言而喻，而该系统的安全性则可谓是重中之重。设计良好的注册登录系统可以保证即使在用户客户端被监听、数据网络传输被拦截、服务端数据被泄露的情况下，也能最大程度地保障用户的密码安全，从而保障用户的资金财产安全。本文结合工程实践，对用户注册登录系统可能面临的攻击和风险点逐一进行分析，并给出对应的应对措施，最终得到一套切实可行的用户注册登录设计方案。

黑客可以通过监听用户的客户端（app或pc浏览器）、拦截用户网络请求、非法入侵服务端数据库、撞库攻击和钓鱼攻击等五种方式窃取用户密码。其中监听客户端包含如下手段（详见黑客破解密码的几种方式）：

1、通过木马对用户使用的设备键盘进行监控，通过分析用户的击键信息即可破解用户密码；

2、对于使用鼠标和图片录入密码的方式，黑客可以通过控制木马程序对用户的屏幕进行录屏监控，从而获取用户密码。

拦截用户网络请求可以细分为如下手段：

1、客户端监听用户请求，抓取数据包，以获取用户明文密码（针对https，详见https真的安全吗）；

2、网络传输链路上拦截用户请求，获取用户密码（仅针对http的明文密码传输）；

3、网络传输链路上拦截用户请求，执行网页替换或部分代码替换，从而骗取用户敏感信息。

非法入侵服务端数据库是指黑客利用服务器的漏洞，非法访问服务端的数据库并窃取用户账号密码等信息。

撞库攻击则是利用很多用户在不同网站使用相同的帐号密码，即黑客可以通过获取用户在A网站的账户密码从而尝试登录B网站。也就是说，即使你自身的网站对用户的密码做了各种各样的防护手段，也无法避免该用户在其他网站的密码被黑客窃取，从而导致该用户在你网站上的密码也被窃取（对于这个问题，后面会给出应对策略）。

钓鱼攻击是指黑客利用欺骗性的电子邮件和伪造的网站登录站点来诱骗用户输入用户名、密码等敏感信息，从而窃取用户密码。其原理和前面提到的拦截用户请求，执行网页替换的方式非常相似。

本人的另一篇博客深入浅出彩虹表原理介绍了密码破解利器——彩虹表。为了更好地理解本文接下来介绍的内容，强烈建议先阅读该博客中的内容。

参考博客App登录模块密码加密方案中给出了一种设计方案：

图中的rule1和rule2方法实际上是对应的是MD5、SHA128、SHA256、SHA512、RipeMD、WHIRLPOOL等不可逆的哈希（hash）算法（关于哈希算法不可逆的原理介绍，详见参考博客为什么说MD5是不可逆哈希算法）。

上述方案存在的致命问题是无法应对前面介绍的“非法入侵服务端数据库”这种攻击（由参考博客2018上半年国内外互联网十大数据库泄露事件可知，非法入侵数据库是黑客批量获取用户账号密码的重要手段之一）。由图中所示，用户注册时，在客户端对明文pass加密得到passStr并保存在数据库中，当黑客非法入侵到服务端数据库并获取到用户的密码passStr后，甚至都不需要破解以得到pass，而直接用passStr登录即可。因而在参考博客加盐hash保存密码的正确方式中提到，即使客户端做了哈希运算，服务端依然需要将得到的密文再进行hash。

此外，图中的方案在登录时采用了向服务器请求随机盐的方式来对明文进行加密的方案，而参考博客加盐hash保存密码的正确方式中却反对使用这种方式，给出的原因是恶意的攻击者可以通过这个逻辑来判断一个用户名是否有效。对于这个理由，你可能会不以为然，因为对于用户请求随机盐的接口，服务器完全可以不校验该用户名是否存在，而只是临时生成一个随机盐返回给客户端，并将该盐存储到缓存中。当用户用该盐生成的密码提交登录请求时再进行校验，并返回“用户名或密码错误”这样的提示即可避免上述问题。对此，我们需要结合刚刚提到的“即使客户端做了哈希运算，服务端依然需要将得到的密文再进行hash”来进行分析。由于服务端需要对客户端的密文再进行一次哈希，如下图所示：

图示中，注册时对明文A只使用了普通的hash，在服务端对密文B使用不同对哈希函数再次进行运算，得到密文C并存储到数据库。登录时，客户端先像服务端请求hash盐，然后对明文A使用加盐的hash，服务端得到了密文D。可问题是，这个时候我们无法验证密文D的正确性！！为此，我们不得不考虑在注册时也使用加盐hash，如下图所示：

图示中，我们注册和登录时都使用了加盐hash，而且，为了保证登录时能校验明文的正确性，我们必须使用和注册时同样的盐，因此盐值不能只是存储中缓存中，而是需要同密文一起存储到数据库中。试想一下，此时用户登录，请求用户盐值，如果该用户存在，则返回其盐值，如果不存在，则不返回盐值。黑客不就可以以此判断该用户是否合法了吗？

至此，我们明白了，通过客户端向服务端获取盐值的方案不合适，那么具体应该怎么办呢？参考博客加盐hash保存密码的正确方式中提到：因为我们已经在服务端进行了恰当的加盐的hash。所以这里使用用户名跟特定的字符串(比如域名)拼接作为客户端的盐是可以的。也就是说，参考博客加盐hash保存密码的正确方式推荐如下方案：

个人对此方案持反对意见。我们在客户端加随机盐的目的是使客户端到服务端之间的密码安全。现在客户端采用了加常量随机盐的方式，由参考博客深入浅出彩虹表原理可知，在彩虹表面前，常量随机盐的意义并不大。那么该如何保障客户端到服务端之间的密码安全呢？

一个可行的方案是使用非对称加密算法RSA（百度的注册登录使用的就是这个算法，RSA属于非对称加密算法，即加密解密使用的密钥不是同一个。关于RSA算法的详细原理见本人的另一篇博客RSA算法原理及其在HTTPS中的应用），具体来说就是用户注册登录时，在提交注册或登录请求前先请求网站的公钥，并使用公钥对明文进行加密，服务端接收到密文之后，先用私钥进行解密，然后再通过加盐的哈希算法加密并存储到数据库中。即客户端和服务端之间的链路通过RSA算法保证密码的安全，而服务端仍然采用随机盐的哈希算法：

实际上，上述方案还存在一个问题：在服务端通过私钥解密之后居然能看到用户的明文密码！！！这肯定是不能接受的！因而实际上，我们在客户端使用RSA加密之前，会先使用哈希算法对明文进行加密，具体流程如下所示：

由图可知，整个链路，除了用户输入时是明文之外，其它地方都是密文，从而可以较好地保证用户的密码安全。为了便于后续描述，我把该方案简称为“哈希+RSA+随机盐哈希”方案。

其实到这里，密码的安全程度已经非常高了，可以直接应用于企业网站系统了。但如果还想在此基础上进一步提高其安全性，还可以往哪个方向努力呢？

可以看到，上述方案对于黑客而言，由于RSA算法的公钥是公开的，因而获取到明文A和获取到密文L是等价的！！假设黑客通过非法入侵数据库得到了用户的密文M及其随机盐salt值，在掌握了服务端加密算法hash2的情况下，就可以利用彩虹表对单个用户进行暴力破解（尽管破解成本很高），最终只需要获取密文L即可。

对此，参考博客加盐hash保存密码的正确方式中也提到了：只要攻击者能够验证一个猜测的密码是正确还是错误，他们就可以使用字典或者暴力攻击破解hash。更深度的防御方法是加入一个保密的key(secret key)进行hash，这样只有知道这个key的人才能验证密码是否正确。这个思路可以通过两种方式来实现。一种是hash通过加密算法加密比如AES，或者使用基于key的hash函数(HMAC)。

以AES（AES、DES等都属于对称加密算法，即加密解密的秘钥是同一个，详见参考博客用不可逆加密纯客户端实现加密及验证）为例（HMAC方案类似，不再赘述），具体方案如下：

该方案是在“哈希+RSA+随机盐哈希”方案的基础上再加了一层AES对称加密。对于对称加密的密钥，博客加盐hash保存密码的正确方式中要求将AES使用的加密key单独存储在一个外部系统中，比如专门用来进行密码验证的物理隔离的服务器。

试想一下，黑客通过非法入侵数据库获取了密文N和随机盐，并且掌握了服务端使用的hash2和AES算法（由于AES的加密key在独立的数据库，因而此处假设黑客只是掌握了加密算法，而没有获取到加密key），那么他是否有可能通过暴力破解以得到密文L呢？

假设黑客猜测密文N破解后的密文为P，这里需要验证P=L。为此，黑客首先将密文P使用hash2算法执行加盐哈希，得到的密文假设为Q，由于黑客不知道AES算法的加密key，因而无法对Q进行运算，也就无法验证Q经过AES(Q, key)加密之后的结果和密文N是否相等。由此可知，只要保护好了key不被泄密，那么黑客的暴力破解就是无效的，因为他无法验证猜测的密码是否正确。我们将该方案简称为“哈希+RSA+随机盐哈希+AES”方案。当然，对应的还有“哈希+RSA+随机盐哈希+HMAC”方案。

本节内容我们来分析上一节得到的三个方案在面对前面介绍的五种泄密方式时的表现。

很显然，该方案对于前面提到的监听客户端的键盘和屏幕等攻击手段无能为力；对于拦截用户网络请求的三种方式中，能避免第一和第二种攻击，但无法解决网页替换攻击（所幸采用https可以解决第二种和第三种攻击，因而本文得到的两个方案在基于https进行加密传输的情况下可以避免拦截用户网络请求的各种攻击）；对于黑客非法入侵服务端数据库，由于密文都是经过加密的，就算使用彩虹表也难以破解；以上加密方案对于撞库攻击和钓鱼攻击均无能为力。

至此可知，用户注册登录系统采用本文最终的三种方案结合https进行网络传输，可以解决用户网络请求拦截攻击和服务端数据库非法入侵，但还是无法避免客户端监听攻击、撞库攻击和钓鱼攻击！！！

其实细想一下，以上三种攻击，已经完全超出了注册登录系统本身所能保护的范围。比如你无法绝对保证用户使用的客户端是安全的，你也无法保证用户在不同网站使用的账号密码是不一样的，你也无法保证用户一定不会访问一个钓鱼网站从而导致密码泄露。因而对于以上三种攻击，我们也不要再奢望通过增加注册登录系统的复杂性而有所改善，完成这个工作的应该另有其人。

绝大多数的大中型互联网公司都有风控系统，该系统最重要的工作就是对用户操作行为进行风险评估，以保证在用户的密码已经被泄漏的情况下，最大限度地保护用户的资金财产安全。风控系统具体的操作思路是：建立用户行为画像，即存储用户日常登录的终端设备的ip地址、设备唯一标识、用户所在地、常用往来交易账户等信息。当用户出现异常操作时，比如异地登录、换新设备登录等，则该操作会被判定为风险操作，从而通过增加邮件、短信等验证机制以确认是用户本人的操作行为，并适时提醒用户更新密码。

至此可知，本文最终得到的三个加密方案“哈希+RSA+随机盐哈希”、“哈希+RSA+随机盐哈希+AES”、“哈希+RSA+随机盐哈希+HMAC”结合“基于https的加密传输”方案可以较好地保障系统自身的数据安全，但无法保障自身系统以外的数据安全。而风控系统则负责保证在用户的密码已经被泄漏的情况下，最大限度地保护用户的资金财产安全。两相结合，就可以有效地保障用户的资金财产安全。

参考博客：

1、http://www.360doc.com/content/18/0318/06/415885_738036451.shtml 黑客破解密码的几种方式

2、https://www.cnblogs.com/guanghe/p/10671666.html https真的安全吗，加密登录其实不简单

3、https://www.jianshu.com/p/26234e36869c App登录模块密码加密方案

4、https://blog.csdn.net/Saintyyu/article/details/102583941 深入浅出彩虹表原理

5、https://wooyun.js.org/drops/%E5%8A%A0%E7%9B%90hash%E4%BF%9D%E5%AD%98%E5%AF%86%E7%A0%81%E7%9A%84%E6%AD%A3%E7%A1%AE%E6%96%B9%E5%BC%8F.html 加盐hash保存密码的正确方式

6、https://www.sohu.com/a/252091442_464012 盘点： 2018上半年国内外互联网十大数据库泄露事件 

7、https://blog.csdn.net/Saintyyu/article/details/55806247 RSA算法原理及其在HTTPS中的应用

8、https://blog.csdn.net/Saintyyu/article/details/102641627 为什么说MD5是不可逆哈希算法

9、https://blog.csdn.net/hj7jay/article/details/80221060 HTTPS连接过程以及中间人攻击劫持

10、https://www.jianshu.com/p/f693cbb87f9e 用不可逆加密纯客户端实现加密及验证

11、https://www.cnblogs.com/chromebook/p/4112329.html RSA、DSA以及ECC

12、https://www.cnblogs.com/tester-xt/p/13174279.html  为什么抓包工具看HTTPS包是明文