登录注册密文传输密码

如何保证用户登录时提交密码已经加密？

其实在接收到了之后再加密是非常方便的，你可以在后台轻松做各种加密，这样几乎可以保证数据拿去也变不成明文内容。但问题是在传输的时候，假设我们不使用 https，即使是使用 https 传输，如何保证用户的数据被提交过来的时候是已经加密过的？

现在有一种方法是用 js 加密。比如：JS_MD5('origiPassword')。但问题是我们还要保证功能的可用性。比如无 JS 环境用 form 也可以提交。假设是注册用户。这时无 JS 的情况传输到后台的时候是明文密码，那么存在数据库的时候可能是这样的 salt + md5(origiPassword, salt)，但当用户下次登录的时候是在有 JS 的环境里，那么，去数据库校验的就会因为不符而登录不上，所以如题？有什么比较好的方法？

如何保证用户登陆时提交密码已经加密？密码是否已加密，需要客户端和服务端建立约定，双方按约定办事就行了。

这里提到的另一个问题是，如何保证传输安全？
最理想的方案当然是走 HTTPS 协议. HTTPS 在理论上是可靠的，但在国内会打一些折扣：你可以随便找一台电脑看看有没有安装商业公司或机构的根证书，这些根证书为线路某节点成为中间人提供了可能性；同时，在木马横行的年代，密码在加密提交前可能就被拿到了，此时 HTTPS 成了摆设，这是为什么国内流行密码控件的一个重要原因。

从成本和需求上考虑，对于众多对安全性要求不高的个人网站，仍然可以考虑采用 HTTP 传输，密码提交前通过 JavaScript 加密。由于 JavaScript 代码暴露在客户端，因此一般通过不可逆的加密方法加密密码，而对于任何摘要式的加密算法，都可以通过类似 md5 字典的方式直接查表获知弱密码，所以要混入 salt 以增加制作字典的成本。可想而知，解密只是时间成本的问题。因此这里的重要前提是“对安全性要求不高”。

如何验证密码呢？一个可行的方法是，客户端提交 md5(password) 密码（如上所述，此方法只是简单保护了密码，是可能被查表获取密码的）。服务端数据库通过 md5(salt+md5(password)) 的规则存储密码，该 salt 仅存储在服务端，且在每次存储密码时都随机生成。这样即使被拖库，制作字典的成本也非常高。
密码被 md5() 提交到服务端之后，可通过 md5(salt + form['password']) 与数据库密码比对。此方法可以在避免明文存储密码的前提下，实现密码加密提交与验证。
这里还有防止 replay 攻击（请求被重新发出一次即可能通过验证）的问题，由服务端颁发并验证一个带有时间戳的可信 token （或一次性的）即可。
当然，传输过程再有 HTTPS 加持那就更好了。

最后，为什么要密码控件？原因之一是上面说的，要防止密码在提交前被截获。当然，还有一些其他原因，工作所限，这里就不说了。

以下是光神的讲解：

中间人攻击（Man-in-the-Middle Attack, MITM）是一种由来已久的网络入侵手段，并且在今天仍然有着广泛的发展空间，如SMB会话劫持、DNS欺骗等攻击都是典型的MITM攻击。简而言之，所谓的MITM攻击就是通过拦截正常的网络通信数据，并进行数据篡改和嗅探，而通信的双方却毫不知情。

彩虹表就是一个庞大的、针对各种可能的字母组合预先计算好的哈希值的集合，不一定是针对MD5算法的，各种算法的都有，有了它可以快速的破解各类密码。越是复杂的密码，需要的彩虹表就越大，现在主流的彩虹表都是100G以上。

该 salt 仅存储在服务端，且在每次存储密码时都随机生成。稍微看过几个开源程序的密码验证部分就能看出来了。有的是一个password字段一个salt字段，有的为了兼容，就是password:salt这样存储，但被拖库的时候，一可以扛彩虹表，二可以拖慢暴力破解速度，其中尤其以扛彩虹表为关键。

 彩虹表和暴力破解是不同的，我们讲暴力破解，一般是词典/遍历攻击，彩虹表，是直接查表。彩虹表一般是O(1)的时间，暴力不一定。

 例如一句
aquickbrownfoxjumpsoverthelazydog
很有可能彩虹表没存这一句
但词典，把
a quick brown fox jumps over the lazy dog
都存下来了
然后组合出这个组合，进行尝试