正文

好多讀者認(rèn)為只要使用了https，加密了http的所有字段，整個通信過程就是安全的了。殊不知，現(xiàn)如今https通信并不是端到端(End to End)，而往往是中間夾雜著代理，有客戶端的代理，也有服務(wù)器端的代理。

而代理的存在使得本來較為嚴(yán)密的、安全的https，存在安全隱患。

[[256298]]

客戶端代理

通常用戶是不知道代理的存在，比如企業(yè)為了監(jiān)控員工https流量，一定會在員工電腦上下手腳，這樣企業(yè)的網(wǎng)管完全可以看到員工的https明文流量，其中也包含用戶的明文密碼。

服務(wù)器代理

通常有服務(wù)器的數(shù)字證書私鑰，可以與客戶端建立https加密通信，自然就可以看到用戶的https明文流量，其中也包含用戶的明文密碼。

以上兩種情況，用戶的明文密碼都有泄漏的風(fēng)險。

一旦前端加密了用戶密碼，即使有代理的存在，依然無法獲得用戶的明文密碼。

前端加密用戶密碼

• 不加鹽的MD5加密密碼

盡管中間代理無法獲得明文密碼，但依然可以拿著截獲的MD5密碼實現(xiàn)登錄，這依然是一個安全隱患。

• 加鹽的一次性密碼OTP

如果每次加密用戶密碼時，同時添加隨機碼Nonce，隨機碼只使用一次，那么每次產(chǎn)生的密碼就是一次性的、動態(tài)變化的。

即使被中間代理截獲，也無法第二次登錄用戶賬戶。

即使沒有中間代理的存在，目前很多https依然使用RSA算法來實現(xiàn)認(rèn)證環(huán)節(jié)、密鑰交換(Key Exchange)環(huán)節(jié)。一旦服務(wù)器的私鑰泄露，歷史上被截獲的https加密流量，將會被輕松破解，其中包括用戶的明文密碼。

這就是為何TLS 1.3會完全拋棄RSA算法，做為密鑰分發(fā)算法的原因，因為它不滿足PFS要求。

PFS要求

PFS，Perfect Forward Secrecy，任何一個安全要素的破解，都不能破解全部數(shù)據(jù)。如果滿足這個條件，則為滿足PFS要求，否則為不滿足。

綜上所述，前端加密用戶密碼，是為了更好滴保護(hù)安全、隱私，即使在https被完全破解的情況下，同樣也可以!