陸英

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

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

客戶端代理

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

服務(wù)器代理

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

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

前端加密用戶密碼

1.不加鹽的MD5加密密碼

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

2.加鹽的一次性密碼OTP

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

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

這就是為何TLS 1.3會(huì)完全拋棄RSA算法，做為密鑰分發(fā)算法的原因，因?yàn)樗粷M足PFS要求。

PFS要求

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

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