思考：Https情况下前端密码是否需要加密

原创文章，转载请标注。https://blog.csdn.net/leeboyce/article/details/135469026

例子：

（1）不加密例子

（2）加密例子

结论：前端账号密码需要加密。

论点一：https是否真的“安全”？

1、Https通信中间掺杂着许多代理（客户端代理、服务器代理等），而正是因为这些代理的出现，使得https也变得不那么安全。

通过代理就能监控https明文数据，从而能够获取到用户未加密的账号密码。

2、抓包原理（Fiddler、Charles、Wireshark等抓包工具）

抓包工具作为中间代理，通过对客户端伪装成服务端和对服务器伪装成客户端的方式，对骗客户端与服务端进行欺骗，从而打到截取明文数据的目的。

其实抓包的原理本质上就是中间人攻击，但前提是用户客户端上安装抓包工具根证书并设置为信任。只要用户不设置证书信任，https还是非常安全的。只要在认证环节出了问题，https的安全性就会失效。

论点二：用户隐私保护

加密能保障用户隐私安全，防止内部人员窃密。

1、保护用户隐私。用户账号密码可能包含其个人身份信息，账号密码泄露会导致其身份隐私信息泄露；

2、防止内部窃密。请求经过服务端必然会留下请求日志或痕迹，任意内部开发人员都能够获取到用户账号密码，会对企业数据安全造成困扰；

3、防止撞库。用户明文账号密码被截获后，会被尝试于不同应用上，对整个互联网账号安全都带来影响。

论点三：提升逆向成本

提升逆向成本。

（1）通过自定义加密算法对账号密码进行加密，提升作弊者的协议伪造成本；

（2）通过在加密算法中加入时间戳或其他随机值，能够避免重放攻击；

（3）通过加入环境检测逻辑，检测当前用户运行环境是否正常。

总之通过对账号密码进行加密，我们能够提升逆向分析的难度。我们弄个在该加密串中加入很多有意义的标识，迫使作弊者必须分析。
当然加密和混淆是不可分割的，只加密不混淆，加密算法明文呈现，加密的效果就会大打则扣。

最后

懂的不多，做的太少。欢迎批评、指正。