1 有隐患登录的验证方式1.1 有隐患登录的验证方式介绍如图所示,从firebug上抓取到我们输入完用户名和密码之后的信息,url:http:///doLogin.php?username=CleverCode&pwd=123456,可以看出,我们的请求方式是Get请求,还有我们现在的密码传输用的是明文传输。可以很清楚的看到我们登录时候传递的URL中附带上了用户名:CleverCode,密码是:123456。 1.2 存在的问题1) GET请求:可以看到,在传输用户名和密码的时候是用的GET请求方式。这种请求方式参数会附带在URL中。这样会带来潜在的安全隐患。建议使用POST请求。 2)传输的过程中密码是明文: 在传输的过程中,发现传输的密码是明文,这个很容易就把用户的密码给泄露了。建议将密码加密后在进行传输。 1.3 潜在的风险在传输的过程中使用了GET请求,并且密码没有进行加密。每次浏览器进行请求的时候,有的浏览器设计公司会记录下每次请求的URL,然后在进行一些行为分析,如果是这样,那么我们的用户的密码将存在非常的大的隐患。很有可能别人窃取。从而进行一些对本公司不利的活动。2 建议改进的登录验证方式2.1 设计方案介绍在设计的过程中,可以使用POST请求,POST请求,在传输过程中参数不会被附加在URL上,这个可以防止它人进行用户行为分析的时候,分析出用户名和密码。在传输的过程中,可以将密码进行加密,然后进行密文传输。密文加密的时候可以使用哈希函数中的md5()算法。Md5()加密的后的密文不会有哈希冲突,是常见的加密方式之一。2.1.1 前台页面源代码
2.1.2 前台页面源代码说明1)传给服务器的数据结构样例:personId:CleverCode passwdMd5: 202cb962ac59075b964b07152d234b70 timestamp:1393998153 passwd: ****** 2)计算当前时间戳: 首先使用php把当前服务器的时间戳赋值给了$loadtime,在js环境加载的时候,首先记录的js的加载时间loadtime = parseInt(new Date().getTime()/1000),这个时间是客户端的时间,在点击完登录按钮之后,在记录var currtime = parseInt(new Date().getTime()/1000)时间,当前的currtime是用js求得的,得到的客户端浏览器所在机器的时间,每个人客户端的时间设置可能都不一样,使用var timestamp = <?php echo $loadtime;?> + currtime – loadtime,就可以得到现在真正的时间。我们只取了在客户端登录的时间差,然后加上服务器的起始时间,那么就可以到的当前时间。 3)密码加密: 首先对用户的密码进行md5加密var passwdMd5 = hex_md5(passwd);,js中md5的加密函数为hex_md5();然后在用户的Id与passwdMd5与时间戳一起md5加密passwdMd5 = hex_md5(personId + passwdMd5 + timestamp),得到真正要传输给服务器的md5密码。 4)迷惑密码: document.login_form.passwd.value = "******",这部分为使用的迷惑密码,并没有多大的实际意义。 2.2 后台验证设计2.2.1后台页面源代码
2.2.2后台页面源代码说明首先获取服务器当前时间戳$nowTime,用当前的时间戳减去传入的时间戳$timestamp,如果大于等于60s说明,响应时间超时,必须放弃这条检测;然后判断当前的用户是否存在;接着从保存用户密码的地方获取用户的密码$passwd,用户在数据库中保存的密码必须是明文的md5值;然后$personId.$passwd.$timestamp进行md5加密得到真正的密码$realPasswd;最后对传入的密码$passwdMd5与$realPasswd进行比较2.3 设计方案的优点1) 使用POST请求传输,避免了url在传输过程中被它人窃取用户名和密码。2) 密码传输的方式不再是明文传输,而是使用密文传输,不容易被破解。 3) 在传输的时候,首先对用户密码的明文进行md5计算,然后在对passwdMd5 =hex_md5(personId + passwdMd5 + timestamp)。为什么不直接将明文md5后就直接传输的原因是,如果有人有足够强大的md5映射库。然后他只需要拿到你的密文之后再进行匹配,即采用枚举破解法,既可以知道了明文。使用的timestamp之后就很难暴力破解了。 4)加密过程中使用时间戳,增加了加密的复杂度,提高了安全性。 2.4 设计方案的不足登录的时候没有设计验证码类似的功能,登录的接口直接裸露出来,很容易被它人模拟http请求,大量请求这个接口,造成这个接口的崩溃。建议自行设计时候,当用户如果输入密码错误N次的时候,需要输入验证码。
版权声明: 1)原创作品,出自"CleverCode的博客",转载时请务必注明以下原创地址,否则追究版权法律责任。 2)原创地址:http://blog.csdn.net/clevercode/article/details/45481409(转载务必注明该地址)。 3)欢迎大家关注我博客更多的精彩内容:http://blog.csdn.net/CleverCode。
|
|