HTTP协议下保证登录密码不被获取最健壮方式
|
副标题[/!--empirenews.page--]
说到在http协议下用户登录如何保证密码安全这个问题：
新浪微博：intsmaze刘洋洋哥
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
}
然后我们在说说用户登录后，我们是否要把用户的密码保存到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保护通讯。 （编辑：淮北站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
