如何保证用户登陆时提交密码已经加密？密码是否已加密，需要客户端和服务端建立约定，双方按约定办事就行了。
这里提到的另一个问题是，如何保证传输安全？
最理想的方案当然是走 HTTPS 协议. HTTPS 在理论上是可靠的，但在国内会打一些折扣：你可以随便找一台电脑看看有没有安装商业公司或机构的根证书，这些根证书为线路某节点成为中间人提供了可能性；同时，在木马横行的年代，密码在加密提交前可能就被拿到了，此时 HTTPS 成了摆设，这是为什么国内流行密码控件的一个重要原因。
从成本和需求上考虑，对于众多对安全性要求不高的个人网站，仍然可以考虑采用 HTTP 传输，密码提交前通过 JavaScript 加密。由于 JavaScript 代码暴露在客户端，因此一般通过不可逆的加密方法加密密码，而对于任何摘要式的加密算法，都可以通过类似 md5 字典的方式直接查表获知弱密码，所以要混入 salt 以增加制作字典的成本。可想而知，解密只是时间成本的问题。因此这里的重要前提是“对安全性要求不高”。
如何验证密码呢？一个可行的方法是，客户端提交 md5(password) 密码（如上所述，此方法只是简单保护了密码，是可能被查表获取密码的）。服务端数据库通过 md5(salt+md5(password)) 的规则存储密码，该 salt 仅存储在服务端，且在每次存储密码时都随机生成。这样即使被拖库，制作字典的成本也非常高。
密码被 md5() 提交到服务端之后，可通过 md5(salt + form[‘password‘]) 与数据库密码比对。此方法可以在避免明文存储密码的前提下，实现密码加密提交与验证。
这里还有防止 replay 攻击（请求被重新发出一次即可能通过验证）的问题，由服务端颁发并验证一个带有时间戳的可信 token （或一次性的）即可。
当然，传输过程再有 HTTPS 加持那就更好了。
最后，为什么要密码控件？原因之一是上面说的，要防止密码在提交前被截获。当然，还有一些其他原因，工作所限，这里就不说了。
