HTTP协议下保证登录密码不被获取最健壮方式

原文：http://www.cnblogs.com/intsmaze/p/6009648.html

HTTP协议下保证登录密码不被获取最健壮方式

 

说到在http协议下用户登录如何保证密码安全这个问题：
    小白可能第一想法就是，用户在登录页面输入密码进行登录时，前台页面对用户输入的密码进行加密，然后把加密后的密码作为http请求参数通过网络发到服务器。
    这样做是无法保证用户的账户安全的，因为稍微懂一点编程知识的人就可以通过你发送的http请求知道了你的密码，小白又说了，我密码加密了，它拿到的也是加密后的密码，它不知道我的原始密码它是无法从登录页面登录的。

原文和作者一起讨论：http://www.cnblogs.com/intsmaze/p/6009648.html

但是小白啊，你有没有想过，有时候我仅仅知道你加密后的明文就够了，我可以自己伪造http请求，把明文加在请求参数里面，一样可以登录系统的。
    大白这时候有话说了，大白：我可以对密码进行加盐。好，我们先看加盐是什么，加盐简单说就是程序对用户设置的原始密码后面追加随机数来加强用户密码的复杂性，然后再对组合后的密码进行加密进行存储，用户每一次登录，前端先对用户输入密码进行加密传输到后端，然后后端获得用户账号到数据库找到该用户的盐，再和传来的明文组合一起进行一次加密后与数据库中的密码进行对比来判断是否是符合用户。但是啊，大白，你看，这样做，并无法控制其他人通过你http请求获得明文，获得后，人家照样大摇大摆使用你的身份登录系统进行操作。
    好，大白让我跟你讲讲加盐的真正意义：加盐的意义不是为了保证密码在网络传输的安全性，而是防止数据库被人入侵后，由于原始密码太过简单，被人分析出来，进而知道了密码。直接对密码进行MD5处理后，反向解密确实难度很大，但还是可以找出破绽的 例如：两个人或多个人的密码相同，通过md5加密后保存会得到相同的结果。破一个就可以破一片的密码。如果用户可以查看数据库，那么他可以观察到自己的密码和别人的密码加密后的结果都是一样，那么，别人用的和自己就是同一个密码，这样，就可以利用别人的身份登录了。那么我们以前的加密方法是否对这种行为失效了呢？其实只要稍微混淆一下就能防范住了，这在加密术语中称为“加盐”。具体来说就是在原有材料（用户自定义密码）中加入其它成分（一般是用户自有且不变的因素），以此来增加系统复杂度。当这种盐和用户密码相结合后，再通过摘要处理，就能得到隐蔽性更强的摘要值。
    小黑说：你说的这些我都懂，我来告诉你最终的方案吧：在用户输入完账号后，后台ajax发送用户的账号到服务器，这个时候服务器为该账号生成一个随机数验证码，响应给前端登录页面。
    当用户输入密码后，前端页面对用户输入的密码进行加密，然后把加密后的明文和获得服务器返回的验证码组合在一起再一次进行加密。然后把该信息发送到服务器，服务器session中保存这这个账号的验证码，服务器会从数据库获取该用户的密码和验证码进行组合再次加密与前端传来的明文进行对比判断。
好，接着让我们分析为什么安全，因为验证码是一次性的,, 所以,你在网络层拿到本次的请求之后,无法做 重放攻击, 因为验证码是不正确的.而当你获取新的验证码, 但你并不知道 组合之前的内容[md5(md5(密码) + 用户的QQ号)] 是什么 , 所以你无法重新发送本次请求实现登陆的目的.32位MD5 + 4位验证码 总计 36位的字符串, 你去破解吧. 估计等你挂了你也破解不出来.至于服务端的校验, 只要将记录下来的MD5值(而不是记录的明文), 进行同样的运算, 得到的结果与提交上来的一样, 即密码正确.验证码的内容是服务器下发的,而且是一次性的,所以 客户端无法伪造, 也无法重用.
下面是QQ之前网页的源代码片段：
Q 网页上的登陆模块(全程HTTP/GET请求).
QQ 在登陆时,对用户输入的密码加密的JS代码为:

 function getEncryption(password, uin, vcode, isMd5) {
        var str1 = hexchar2bin(isMd5 ? password : md5(password));
        var str2 = md5(str1 + uin);
        var str3 = md5(str2 + vcode.toUpperCase());
        return str3
    }

白话就是: md5(md5(md5(密码) + 用户的QQ号) + 验证码)
现在你知道如何在http协议下保证密码安全性了没有。

然后我们在说说用户登录后，我们是否要把用户的密码保存到session中。

以前同事写的密码修改部分代码，发现将用户登录的密码存在session中，然后判断原密码时直接从session中读取。

把密码存在session中安全吗?
session的保存方式相对来说比较安全，因为信息存储在服务器的 
而cookie的方式由于对服务器端来说是不可控的，始终对用户信息泄露是一个危险，但是也有很多采用cookie存储用户信息的，通常是采用加密的方式来进行处理。
我们经常看到很多网站设置记住用户名密码，就是采用cookie的方式

可行性上，我不建议这么做。就连sun公司在是设置password的时候，都用transient 来管理， private transient String password;都不希望password序列化掉， 所以我们跟不能为了方便而把密码存入session中来为了方便。 

最后我们谈谈加密的本质：它其实是对原有内容的混淆，目的是提高从表面结果反推达到目的的成本。
在网页提交（其实所有的通信都有这个问题）密码这个问题上，需要有几个维度来保证安全，

 

首先是切面的安全性，对于一次提交首先保护的是密码本身，从最早的Base64到MD5或是SHA都可以做到这一点，但是Base64是可逆的，对于密码本身的保护是很弱的，哈希算法解决了这个问题，将不同长度的数据转换成统一长度的大数字，而理论上这个数字对应无穷多解，但限于密码的输入有限制，其实是可逆的，所以从1次混淆的MD5变成了3次混淆的SHA，但是随着现代计算机技术的进步，逆运算的成本不断降低，人们不得已要使用更大的数字来提高这个难度，但是为了向成本和发展妥协，人们不得已使用统一的算法，在CS时代由于很难侵入到CS两端，所以相对的双方使用的算法是保密的，破解难度相对比较大，BS由于为了保证开放性，特别是js本身就是明文算法，所以其实只能说防君子不妨小人，所以就有了安全控件，控件的唯一目的是用2进制代码来隐藏加密的算法，不知道算法，也就很难破解原文。

第二维度就是时间，如果密码一样加密结果也会一样，那么在不使用原文的情况下，可以使用加密过后的数据来模拟用户登录的动作也是可以的，所以纯粹对密码的加密其实不能解决这个问题，所以有了盐值，让同一个数据在不同情况下结果依旧不一致，但是盐值需要约定，总会被人找出规律，只是成本又高了点，所以还是不安全，这就引发了通讯安全的问题。所以出现了https使用非对称加密来保护数据通路上的安全，让通讯变得不可窥视。但是还有个东西叫木马，所以人们在输入上继续做文章，包括混淆输入，就是软键盘，好的控件不会把明文存在内存里，这很重要，以前的VB、Dephi密码控件都仅仅看不到，实际内存里面都是明文，很容易被病毒和木马利用，所以一般来说现在最安全的bs系统使用控件保护输入，隐藏自己的HASH算法，用HTTPS保护通讯。