閱讀 :950

　　如何保證用戶登陸時(shí)提交密碼已經(jīng)加密?密碼是否已加密，需要客戶端和服務(wù)端建立約定，雙方按約定辦事就行了。

　　這里提到的另一個(gè)問題是，如何保證傳輸安全?

　　最理想的方案當(dāng)然是走 HTTPS 協(xié)議. HTTPS 在理論上是可靠的，但在國內(nèi)會(huì)打一些折扣：你可以隨便找一臺(tái)電腦看看有沒有安裝商業(yè)公司或機(jī)構(gòu)的根證書，這些根證書為線路某節(jié)點(diǎn)成為中間人提供了可能性;同時(shí)，在木馬橫行的年代，密碼在加密提交前可能就被拿到了，此時(shí) HTTPS 成了擺設(shè)，這是為什么國內(nèi)流行密碼控件的一個(gè)重要原因。

　　從成本和需求上考慮，對于眾多對安全性要求不高的個(gè)人網(wǎng)站，仍然可以考慮采用 HTTP 傳輸，密碼提交前通過 JavaScript 加密。由于 JavaScript 代碼暴露在客戶端，因此一般通過不可逆的加密方法加密密碼，而對于任何摘要式的加密算法，都可以通過類似 md5 字典的方式直接查表獲知弱密碼，所以要混入 salt 以增加制作字典的成本。可想而知，解密只是時(shí)間成本的問題。因此這里的重要前提是“對安全性要求不高”。

　　如何驗(yàn)證密碼呢?一個(gè)可行的方法是，客戶端提交 md5(password) 密碼(如上所述，此方法只是簡單保護(hù)了密碼，是可能被查表獲取密碼的)。服務(wù)端數(shù)據(jù)庫通過 md5(salt+md5(password)) 的規(guī)則存儲(chǔ)密碼，該 salt 僅存儲(chǔ)在服務(wù)端，且在每次存儲(chǔ)密碼時(shí)都隨機(jī)生成。這樣即使被拖庫，制作字典的成本也非常高。

　　密碼被 md5() 提交到服務(wù)端之后，可通過 md5(salt + form['password']) 與數(shù)據(jù)庫密碼比對。此方法可以在避免明文存儲(chǔ)密碼的前提下，實(shí)現(xiàn)密碼加密提交與驗(yàn)證。

　　這里還有防止 replay 攻擊(請求被重新發(fā)出一次即可能通過驗(yàn)證)的問題，由服務(wù)端頒發(fā)并驗(yàn)證一個(gè)帶有時(shí)間戳的可信 token (或一次性的)即可。

　　當(dāng)然，傳輸過程再有 HTTPS 加持那就更好了。

　　最后，為什么要密碼控件?原因之一是上面說的，要防止密碼在提交前被截獲。當(dāng)然，還有一些其他原因，工作所限，這里就不說了。

下一篇:sitecore引用作為一個(gè)強(qiáng)大的在線客戶體驗(yàn)管理 下一篇 【方向鍵 ( → )下一篇】

上一篇:航班管家這款應(yīng)用應(yīng)該做哪些改進(jìn)? 上一篇 【方向鍵 ( ← )上一篇】