【微思探索】【实战】www.wisexplore.com为什么不用https，但是已足够安全

微思探索没有使用https，但是笔者认为已足够安全。

这么说的原因有以下几点：

1.未登录场景比如登录，注册，忘记密码等，我们采取了足够的安全措施，比如阿里云滑块保护，非对称秘钥协商，短信检验码认证等

2.登录后的所有后端接口都受token保护，请参考笔者的前一篇文章“账号系统有了cookie，为什么还需要token”

首先说一下登录前的场景，以注册为例，阿里云滑块为各个接口的保护提供了基础，由于未登录前不知道是哪个用户在操作，有可能是程序直接刷我们后台接口，举个例子，如果没有滑块保护，发送短信接口直接暴露给用户，有可能就被用户狂刷，那后果可想而知。有人说即使滑块也不是安全的，比如腾讯的滑块就被人破解过，这我只能说它设计的还不够好，现在我选择了阿里云的滑块，一方面滑块滑动的过程以及轨迹让程序不容易模拟，另一方面是滑块滑完后，用户还需选择某个汉字，又加了一重安全保障。所以我选择相信阿里云的滑块，以它为基础，为其它接口提供保护。

以下是注册的流程：

1.滑块校验通过后返回的p-code作什么用？p-code是一次性code，对后续接口调用作保护，用户无法伪造，无论接口调用成功还是失败，都会返回p-code,也就是说，后续所有接口调用都在p-code的保护之下；

2.p-code保护秘钥协商接口，为什么要作秘钥协商？这是参考了https的机制，在没有https保护的情况下，我们需要类似的非对称加密算法来作对称秘钥的协商，非对称加密的最终目的是能协商出一个对称秘钥，然后使用这个对称秘钥对用户密码作加密处理，这样密码是绝对安全的；

3.对称秘钥协商完后，后续的发送短信还有最后的注册接口，都是在p-code的保护之下，所以也是安全的；

4.针对p-code我们也会有限流，对各个接口作限流保护。

5.注册接口的所有参数，都会使用对称秘钥作hmac sha256签名，同时对密码作AES加密，保证所有参数受到保护。

p-code如何起到保护作用?首先p-code是一次性的随机码，再者p-code会跟用户的一些信息绑定（虽然用户还未登录），针对这些用户信息作限流。p-code总是放在http header中，你要知道，只要在http header中随便放一个头，就能有效防止CSRF跨站伪造攻击。

秘钥协商时为什么要前端生成对称秘钥？由于作非对称秘钥协商需要公钥和私钥，私钥保存在服务器，公钥直接保存在js，前端生成对称秘钥的原因是：使用公钥对对称秘钥作rsa加密的结果也只有服务器才能解密，就算请求被人拦截，由于不知道私钥，也无从解密。反过来说，如果对称秘钥由后端生成，后端用私钥加密的结果并无安全性可言，因为公钥在js，每个人都可以轻而易举获取公钥，使用公钥就能将其解密。

在对称秘钥被有效保护的情况下，再通过对称秘钥来对密码作AES加密，这样就可以有效地保护用户输入的密码，以及对各个参数作hmac sha256签名，可以有效地保护各个参数不被篡改，不被重放，不被伪造。

综上，微思探索借鉴了https的机制，再加上hmac签名机制，以及AES加密机制，保证了在http的情况下，也是安全的。

文章已经收录在此：