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

   <h2>前言</h2>    <p>本项目的简介里提到，前端使用 WebScrypt 脚本 Hash 口令，可对「隐私嗅探」起到一定的防护。</p>    <p>当然现在不少网站部署了 HTTPS 协议，因此无需再考虑通信风险。但对于仍在使用 HTTP 的网站，前端 Hash 又能起到多大的效果？</p>    <h2>攻击类型</h2>    <p>通信上的攻击，通常可分「嗅探」和「劫持」。</p>    <h3>嗅探</h3>    <p>嗅探，即攻击者窃听通信流量。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/63f5b4587a4dab9df80d902730f64abd.png"></p>    <p>假如我们的登录过程被嗅探，那么前端提交的 dk 就会泄露。而 dk 是身份凭据，泄露即意味着 <strong>攻击者用它也能登上该账号</strong> 。所以账号被盗用，显然是无法避免的。</p>    <p>不过，相比传统提交，风险其实已降低了不少：</p>    <p>传统提交，口令大多是毫不避讳，直接明文发送的。最多也只是在前端页面中，进行低成本 Hash 再提交。因此攻击者可通过嗅探到的数据，配合页面中的算法，轻易破解口令。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/154e798bcd4e10223c1bcc41ee22945f.png"></p>    <p>但现在，攻击者嗅探到的 dk，是口令经过 <strong>高成本 Hash</strong> 的计算结果。攻击者若想通过 dk 还原口令，得花费巨大的算力。</p>    <p>因此最终：账号被盗，口令拿不到。那些使用类似口令的其他账号，就幸免于难了。</p>    <p>注意，这里的「被盗」是指能被攻击者使用，但未必就能改掉口令。后续文章会讨论这个问题。</p>    <h3>劫持</h3>    <p>嗅探是静默的，通常不篡改或注入流量。因此流量只是失去了隐蔽性，并没有破坏完整性。</p>    <p>然而现实中，攻击者大多有主动出击的能力。例如中间人攻击，或是数据包注入，能对流量实施篡改。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/9f3b6cefe56b54b1975c86bdfec60bf1.png"></p>    <p>既然能修改流量内容，攻击者即可往登录页面中植入一段 JS 恶意代码，这样就能从应用层发起攻击，直接读取表单元素的口令值。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/97b66dc88a8d95b2774810ad060245d4.png"></p>    <p>事实上，用户在页面中的一举一动，都能被恶意代码所监控，甚至在提交之前，输入的内容就已被悄悄发送到后台了。</p>    <p>因此对于流量劫持，前端 Hash 是无法防止口令泄露的。</p>    <h2>结论</h2>    <p>在不安全的通信下，使用前端 Hash 的效果：</p>    <ul>     <li> <p>对于嗅探，虽不能防止账号被盗用，但可有效防止明文口令泄露。</p> </li>     <li> <p>对于劫持，明文口令仍能轻易窃取。</p> </li>    </ul>    <p>所以前端 Hash 只能起到部分效果，无法代替 HTTPS 的功能。</p>    <p> </p>    <p>来自：https://github.com/EtherDream/WebScrypt/blob/master/doc/client-hash-via-insecure-network/README.md</p>    <p> </p>