陸英

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

而代理的存在使得本來較為嚴密、安全的https，“存在”安全隱患。

客戶端代理

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

服務器代理

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

以上2種情況，用戶的明文密碼都有泄漏的風險。但如果前端加密了用戶密碼，即使有代理的存在，依然無法獲得用戶的明文密碼。

前端加密用戶密碼

1.不加鹽的MD5加密密碼

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

2.加鹽的一次性密碼OTP

如果每次加密用戶密碼時，同時添加隨機碼Nonce，隨機碼只使用一次，那么每次產(chǎn)生的密碼就是一次性的、動態(tài)變化的，即使被中間代理截獲，也無法第二次登錄用戶賬戶。

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

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

PFS要求

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

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