目前的现状： 客户端直接传输 userName／password 到后台（OA）系统，后台系统转发登陆请求到用户中心登陆。

问题：

  • 密码明文传输；

最理想的方式： 从一个接口拿到一个临时令牌（token），令牌和用户名绑定，令牌生产规则还可以混入请求IP，时间戳等。 客户端登录，包含该token来加密，服务器解密验证，同时token失效以保证请求不会被重放登录。

目前选择的方式： 加密采用RSA方式，增加2个接口：

1，获得RSA加密的公钥及随机令牌：

  • 公钥：走配置中心，可更换；
  • token（随机令牌）：暂定规则为随机数+时间戳 ，还可以选择用户名，访问IP等；

redis存储数据格式：userName:token

例如： 15077712345 : 12579879571484884761768

2， 加密登录接口：

  • password：RSA(password)
  • sign：HMAC ，防篡改。signValue：userName + RSA(password) + token。CRC也行。

后续如果需要安全升级，还可以进一步提升安全度：

  • RSA升级，一个用户一个私钥；
  • token升级，单次生效（防止重放攻击），增加生成规则复杂度（增加破解难度）；

但是这些都和客户端无关的，后端修改直接上线即可。客户端只需要遵守调用规则，先拿令牌然后登录就行。

解决的问题：

1，中间人攻击（MITM：Man-in-the-middle attack）： 是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

一个中间人攻击能成功的前提条件是攻击者能将自己伪装成一个参与会话的终端，并且不被其他终端识破。大多数的加密协议都专门加入了一些特殊的认证方式以阻止中间人攻击。例如：SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发，并且能执行双向身份认证。

2，HTTPs到底做了什么？ TLS握手阶段需要进行秘钥交换和服务端认证这两个重要的操作。

秘钥交换是为了在不安全数据通道中产生一个只有通信双方知道的共享秘钥（Premaster Secret），进而生成Master Secret以及后续对称加密 Session Key 和 MAC Key。而客户端之所以要进行服务端认证，是为了确保连接到拥有网站私钥的合法服务器。

img

图片来源： https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

Client Random 和 Server Random 明文传输，中间人可以直接查看。客户端生成 Premaster Secret 后，用服务端证书公钥加密后发送，如果服务端拥有对应的私钥，就可以成功解密得到 Premaster Secret。这时，客户端和服务端拥有相同的 Client Random、Server Random 和 Premaster Secret，可以各自算出相同的后续所需 Key。 可以看到，这种方式合并了密钥交换和服务端认证两个步骤，如果服务端能解出 Premaster Secret，也就意味着服务端拥有正确的私钥。中间人没有私钥，无法得到 Premaster Secret，也就无法解密后续流量。

3，HMAC那里用？ 摘要算法。MD5，CRC。

*暴力破解对一切加密都有效，所以只有更好的加密，没有最好的。提升加密强度的过程中时一个增加破解成本的过程。破解成本只要高于被加密对象的价值，我认为就是有效的加密。 *

参考资料：