内容简介：好多读者认为只要使用了https，加密了http的所有字段，整个通信过程就是安全的了。殊不知，现如今https通信并不是端到端(End to End)，而往往是中间夹杂着代理，有客户端的代理，也有服务器端的代理。而代理的存在使得本来较为严密的、安全的https，存在安全隐患。
正文
好多读者认为只要使用了https，加密了http的所有字段，整个通信过程就是安全的了。殊不知，现如今https通信并不是端到端(End to End)，而往往是中间夹杂着代理，有客户端的代理，也有服务器端的代理。
而代理的存在使得本来较为严密的、安全的https，存在安全隐患。
客户端代理
通常用户是不知道代理的存在，比如企业为了监控员工https流量，一定会在员工电脑上下手脚，这样企业的网管完全可以看到员工的https明文流量，其中也包含用户的明文密码。
服务器代理
通常有服务器的数字证书私钥，可以与客户端建立https加密通信，自然就可以看到用户的https明文流量，其中也包含用户的明文密码。
以上两种情况，用户的明文密码都有泄漏的风险。
一旦前端加密了用户密码，即使有代理的存在，依然无法获得用户的明文密码。
前端加密用户密码
- 不加盐的MD5加密密码
尽管中间代理无法获得明文密码，但依然可以拿着截获的MD5密码实现登录，这依然是一个安全隐患。
- 加盐的一次性密码OTP
如果每次加密用户密码时，同时添加随机码Nonce，随机码只使用一次，那么每次产生的密码就是一次性的、动态变化的。
即使被中间代理截获，也无法第二次登录用户账户。
即使没有中间代理的存在，目前很多https依然使用RSA算法来实现认证环节、密钥交换(Key Exchange)环节。一旦服务器的私钥泄露，历史上被截获的https加密流量，将会被轻松破解，其中包括用户的明文密码。
这就是为何TLS 1.3会完全抛弃RSA算法，做为密钥分发算法的原因，因为它不满足PFS要求。
PFS要求
PFS，Perfect Forward Secrecy，任何一个安全要素的破解，都不能破解全部数据。如果满足这个条件，则为满足PFS要求，否则为不满足。
综上所述，前端加密用户密码，是为了更好滴保护安全、隐私，即使在https被完全破解的情况下，同样也可以!
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
