前端 Hash 可否對抗不安全的通訊

前言

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

固然如今很多網站部署了 HTTPS 協議，所以無需再考慮通訊風險。但對於仍在使用 HTTP 的網站，前端 Hash 又能起到多大的效果？

攻擊類型

通訊上的攻擊，一般可分「嗅探」和「劫持」。

嗅探

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

假如咱們的登陸過程被嗅探，那麼前端提交的 dk 就會泄露。而 dk 是身份憑據，泄露即意味着 攻擊者用它也能登上該帳號 。因此帳號被盜用，顯然是沒法避免的。

不過，相比傳統提交，風險其實已下降了很多：

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

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

所以最終：帳號被盜，口令拿不到。那些使用相似口令的其餘帳號，就倖免於難了。

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

劫持

嗅探是靜默的，一般不篡改或注入流量。所以流量只是失去了隱蔽性，並無破壞完整性。

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

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

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

所以對於流量劫持，前端 Hash 是沒法防止口令泄露的。

結論

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

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

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

因此前端 Hash 只能起到部分效果，沒法代替 HTTPS 的功能。