前端 Hash 能否對抗不安全的通信

前言

本項目的簡介里提到，前端使用 WebScrypt 腳本 Hash 口令，可對「隱私嗅探」起到一定的防護。

當然現在不少網站部署了 HTTPS 協議，因此無需再考慮通信風險。但對于仍在使用 HTTP 的網站，前端 Hash 又能起到多大的效果？

攻擊類型

通信上的攻擊，通常可分「嗅探」和「劫持」。

嗅探

嗅探，即攻擊者竊聽通信流量。

假如我們的登錄過程被嗅探，那么前端提交的 dk 就會泄露。而 dk 是身份憑據，泄露即意味著 攻擊者用它也能登上該賬號 。所以賬號被盜用，顯然是無法避免的。

不過，相比傳統提交，風險其實已降低了不少：

傳統提交，口令大多是毫不避諱，直接明文發送的。最多也只是在前端頁面中，進行低成本 Hash 再提交。因此攻擊者可通過嗅探到的數據，配合頁面中的算法，輕易破解口令。

但現在，攻擊者嗅探到的 dk，是口令經過 高成本 Hash 的計算結果。攻擊者若想通過 dk 還原口令，得花費巨大的算力。

因此最終：賬號被盜，口令拿不到。那些使用類似口令的其他賬號，就幸免于難了。

注意，這里的「被盜」是指能被攻擊者使用，但未必就能改掉口令。后續文章會討論這個問題。

劫持

嗅探是靜默的，通常不篡改或注入流量。因此流量只是失去了隱蔽性，并沒有破壞完整性。

然而現實中，攻擊者大多有主動出擊的能力。例如中間人攻擊，或是數據包注入，能對流量實施篡改。

既然能修改流量內容，攻擊者即可往登錄頁面中植入一段 JS 惡意代碼，這樣就能從應用層發起攻擊，直接讀取表單元素的口令值。

事實上，用戶在頁面中的一舉一動，都能被惡意代碼所監控，甚至在提交之前，輸入的內容就已被悄悄發送到后臺了。

因此對于流量劫持，前端 Hash 是無法防止口令泄露的。

結論

在不安全的通信下，使用前端 Hash 的效果：

• 對于嗅探，雖不能防止賬號被盜用，但可有效防止明文口令泄露。

• 對于劫持，明文口令仍能輕易竊取。

所以前端 Hash 只能起到部分效果，無法代替 HTTPS 的功能。

來自：https://github.com/EtherDream/WebScrypt/blob/master/doc/client-hash-via-insecure-network/README.md