這裏提到的另壹個問題是，如何保證傳輸安全？
最理想的方案當然是走 HTTPS 協議. HTTPS
在理論上是可靠的，但在國內會打壹些折扣：妳可以隨便找壹臺電腦看看有沒有安裝商業公司或機構的根證書，這些根證書為線路某節點成為中間人提供了可能性；同時，在木馬橫行的年代，密碼在加密提交前可能就被拿到了，此時
HTTPS
成了擺設，這是為什麽國內流行密碼控件的壹個重要原因。
從成本和需求上考慮，對於眾多對安全性要求不高的個人網站，仍然可以考慮采用
HTTP 傳輸，密碼提交前通過 JavaScript 加密。由於
JavaScript
代碼暴露在客戶端，因此壹般通過不可逆的加密方法加密密碼，而對於任何摘要式的加密算法，都可以通過類似
md5 字典的方式直接查表獲知弱密碼，所以要混入
salt
以增加制作字典的成本。可想而知，解密只是時間成本的問題。因此這裏的重要前提是“對安全性要求不高”。
如何驗證密碼呢？壹個可行的方法是，客戶端提交
md5(password)
密碼（如上所述，此方法只是簡單保護了密碼，是可能被查表獲取密碼的）。服務端數據庫通過
md5(salt+md5(password)) 的規則存儲密碼，該 salt
僅存儲在服務端，且在每次存儲密碼時都隨機生成。這樣即使被拖庫，制作字典的成本也非常高。
密碼被 md5() 提交到服務端之後，可通過 md5(salt +
form['password'])
與數據庫密碼比對。此方法可以在避免明文存儲密碼的前提下，實現密碼加密提交與驗證。
這裏還有防止 replay
攻擊（請求被重新發出壹次即可能通過驗證）的問題，由服務端頒發並驗證壹個帶有時間戳的可信
token （或壹次性的）即可。
當然，傳輸過程再有 HTTPS 加持那就更好了。
最後，為什麽要密碼控件？原因之壹是上面說的，要防止密碼在提交前被截獲。