现在想做两个登陆验证:
第一个:
管理员登陆后台的登陆验证第二个:
会员的登陆验证,可以保留登陆过期时间的那种,其实以前是搞asp的方法,我倒也会,但是安全方便自从搞了php之后,才知道自己有好多的不足。
想问一下,如果第二个登陆验证在客户端,保留cookie的话,在cookie里面存储什么呢?是存入加密后的用户名和密码?
到用户第二次登陆的时候,再通过解密之后查询数据库,看是否能通过验证?
总之对这一块安全意识,太不了解了,请大家说一下吧。

解决方案 »

  1.   

    可以不存用户名和密码
    自定一个混淆码,比如123abc,写在配置文件中,比如叫做$h
    登陆后,把,比如 用户ip/用户id/混淆码,连在一起,作为一个字符串,中间可以加分隔符,为了以后取出时 分词方便
    比如 $s = $u_ip.'-'.$u_id.'-'.$h;
    另外把 $s,用md5加密,产生另外一个字符串,比如叫 $s_md5 = md5($s);
    把两个字符串保存到 cookie里面,
    $_COOKIE['s'] = $s;
    $_COOKIE['s_md5'] = $s_md5;之后,用户刷新页面时,后台php,先判断是否有 $_COOKIE['s'],有,说明登陆过了
    再比较 md5( $_COOKIE['s'] ) 和 $_COOKIE['s_md5'] 是否相等
    相等,说明用户没有篡改 cookie
    这时,就可以把 $_COOKIE['s'] 用分隔符 分词后,得到程序需要的值,比如$u_id如果源代码是公开的,显然,混淆码$h,不能让用户知道,否则用户自己将能构造,经得起验证的$_COOKIE['s_md5'],
    所以混淆码$h,时不时还可以改改,更健康……
    另外,凡程序需要用到的,有特殊意义的会话内容,都要放到$s中,保证用户没有篡改
    比如还要用到 用户当前现金数,我不想每次查数据库了,那就
     $s = $u_ip.'-'.$u_id.'-'.$u_money.'-'.$h;
      

  2.   

    是不需要保留任何东西的,不保留比保留任何东西都安全。
    你就是将生成的验证码存在一个隐藏域中,然后和提交的输入的验证码进行比较不过现在这种模块用的最多的是用Ajax当然,楼上的大鸟说的也是一种方案
      

  3.   

    谢谢一楼的朋友您说:“相等,说明用户没有篡改 cookie ”
    不明白这句话的意思?请问什么时候不相等啊?
      

  4.   

    那么discuz就是把三者有机的结合在一起,保证安全,准确,持久。在客户端存放sid,auth这两个信息。sid是sessionid的简写,其实就是表XX_sessioins的sid,auth是一个认证字符串,它是经过加过密的,只要authkey不被公布,能保证足够的安全性。客户端的这两个值都可以改变(因为是存放在cookie里的吗),但是只要不同时改变,那么就可以通过其中的一个而自动更新另一个,否则,如果都改变,那么就退出登陆了
    请问上边 这段话:但是只要不同时改变这句话怎么理解啊?
      

  5.   

    将用户信息存储在cookie里本身就是不安全的作法,不管你是加密还是未加密.
    如果非要这么做,可以用非对称加密方式.服务器保存用户的公钥和私钥.
    将用户信息以公钥的形式加密码传送给客户端,保存在cookie里.
    下次再取时,用私钥解密用户信息.
      

  6.   

    如果你用户量不大的话,且是企业应用,就用session
    每次让用户登录
      

  7.   

    建议lz使用session。
    就算是很多大型系统也要用到session,
    在cookie上钻牛角尖,没有太大意义。
      

  8.   

    使用,正在活动中的登陆用户信息,直接用session。如果是登陆状态保存n周,这种功能,使用cookie。
    cookie中可以保存用户ID和一个用来表示认证状态的值,
    保存的内容做可逆转加密,在服务器端解密后读取内容就可以了。注意,cookie里面千万不要保存密码。
      

  9.   

    cookie写入用户名就可以了
    登入后要是修改资料和删除要求要重新输入密码后修改删除
      

  10.   


    在用户的浏览器保存密码怎么了啊?如果不知道hash的话用md5加密之后,别人能解密?
      

  11.   

    首先推荐用session,因为session是保存在服务器上的,在本地cookie只存一个sessionid,所以就算改了,也只是相当于未登录状态如果一定要用cookie,相对来说就麻烦了,但记下用户名和密码是大大不必的了,你登录成功后可以记录
    $t = time();
    $key = "shit"; //这个自己随便改
    $_COOKIE["username"] = $username;
    $_COOKIE["time"] = $t;
    $_COOKIE["authcode"] = md5($username.$t.$key);
    这样,在需要验证登录的地方首先判断这三个cookie是否都存在,如果有不存在的,就未登录
    然后,再登录$t,是不是当天的cookie,如果不是,未登录
    最后,再 md5($username.$t.$key) == $_COOKIE["authcode"]  判断这两个是否相等,不等则未登录第二步只是一个例子,如果不加,用户只要成功登录过一次,一样可以篡改成以前登录过的用户名、时间、key,所以最好把时间验证也加进去,如果用户用以前登录过的相关信息想伪造登录的状态,这样就通不过了。
      

  12.   

    1. 在需要验证登录的地方首先判断这三个cookie是否都存在,如果有不存在的,就未登录 
    2. 再验证$t ==> date("Y-m-d", $t),是不是当天的时间,如果不是,未登录 
    3. md5($username.$t.$key) == $_COOKIE["authcode"]  判断这两个是否相等,不等则未登录 
      

  13.   


    1.当然可以解密。虽然可以通过改变加密内容提高安全性,但是没有绝对,把密码保存到cookie始终都是一个隐患。
     弄不好,反而画蛇添足,把ID/密码全部提供给黑客。
    2.cookie没有保存密码的必要。从cookie的信息中只要可以得到可以确定会员ID的内容既可,保存密码,多此一举。
     密码是为了确定访问者使用的ID是其正确的拥有者,也就是说,只有在手动输入的时候,密码才起到其本该有的功效。
     你能举出必须在cookie中保存密码的理由吗?
      

  14.   


    请问dz不也是把用户名和密码保存在cookie当中了吗?
      

  15.   

    在cookie中保存密码并不是以上理由的必要条件。
      

  16.   


    失败是成功之母,有些东西你可以尝试一下。dz是怎么做的我不知道,但据我所知,dz的技术水准并不高。
      

  17.   


    方法可行...安全系数问题
    md5($key.$username.$t.$key);or $key >= 96 char
    $t = microtime(true);
      

  18.   

    你可以参考一下discuz的登陆验证机制。
      

  19.   

    对了,我上面说的有问题,主要早上起得太早,头昏……
    $s = $u_ip.'-'.$u_id.'-'.$h; 
    $_COOKIE['s'] = $s; 
    这不需要保存到 $_COOKIE['s'],否则就变成明码了……
    比如 cookie 保存 $_COOKIE['u_ip'] ,$_COOKIE['u_id'],$_COOKIE['s_md5']
    后台判断 $_COOKIE['s_md5'] 是否和 md5( $_COOKIE['u_ip'].'-'.$_COOKIE['u_id'].'-'.$h; ) 相等
    相等,以上cookie都有效
    总体就是,当源代码公开后,$s串的格式被知道,用户可以构造 $s_md5 的cookie。加入混淆码$h,就让人难做
    你说这个可安全,我觉得通常网站用用还行吧,记得以前用网行接口的时候,它返回用户支付成功,也是类似这种混淆码方式
    当然,现在的网行接口返回就没用过了,也许向楼上说的非对称加密
    session主要独占性方法/并且消耗服务器资源,一般管理员界面用还行吧,前台用户太多,或者用php输出较大文件,就比较那啥……
      

  20.   

    使用SSL 再使用 USB_KEY+个人证书.呵呵.这样OK了.
      

  21.   

    cookie写入用户名就可以了 
    登入后要是修改资料和删除要求要重新输入密码后修改删除
      

  22.   

    已经发了一份完美的解决方案到楼主的邮箱当中了,注意查收发件人:[email protected]