表单数据加密

今天做实验，发现自己做的一个Web应用中，进行用户登录时，居然在请求报文中以明文的方式将用户名和密码Post到服务器，显然这是很低级的，很不安全的。

查阅资料后，发现网友们推崇的还是用https，认为这是终极解决办法，当然部分网友认为https略显麻烦，且也不是100%可靠。

下文摘录的是网友们推荐的一些http中的解决办法，虽然也不是100%可靠，但实现简单，使用方便。

1、用临时token

浏览器打开页面时，服务器生成一个token，返回给客户端，客户端登录时，还是要加密，当然是包含该token来加密，然后返回给服务器，服务器解密验证，同时token失效以保证请求不会被replay登录，然后服务器生成session id返回给客户端，后面在浏览进程中以session id来判断用户。
客户端的加密，即使不可逆，如果每次加密后都是一样内容，那等于没加密，加入服务器提供的临时token来保证加密结果每次都不一样。
服务器接收到请求后，取用户注册时使用的密码密文跟临时token加密后进行比对。
临时token的生成，可以混入请求IP、时间戳、用户代理（userAgent）。
以上仅个人假设的方案，未实施过，仅供参考，http的传输，太不安全。

2、用验证码

在用户登录时将输入的密码和验证码合并并计算MD5，最终传输的是用户名和合并之后的MD5。准确地说应该是：

MD5（MD5（密码）+验证码）或者是MD5（验证码+MD5（密码））

到服务器端，数据库中存储的是MD5（正确密码），可以取出来进行验证。

每次登录产生的验证码不同，而且传输的是图片，嗅探者无法获取到该图片内容，每次登录所传输的密文也不同，即使黑客嗅探到MD5也不能通过该MD5登录。后台验证方面也不需要做太多改动，稍微修改下判断逻辑就可以了。

上述两种方法本子上是一致的，不同的是，前者用的临时token，后者用的验证码，

还要注意，由于客户端的计算一般通过JavaScript来实现，所以如果攻击者修改了本地的JavaScript，仍然有可能轻松取走密码。