shrek_munich 发表于 2013-11-7 11:17
nono，那个字符串只是用来匹配验证帐户有效性而已，信息加密用的是密码本身
呃。。。我好像也没理解错。。是这个意思是，字符串是匹配验证账户有效性的，那这次的不就等于说是服务器认定你已经匹配了么，也就是你是登录状态了，那我知道不知道密码又有什么关系。。。
或者那位同志的意思是，服务器必须再验证客户端是不是登录过的，才能登录？那不就登录密码还是记录在本地不上传服务器么。。。
allesegal 发表于 2013-11-7 11:23
你这个意思说的还是，用你的办法，别人是得不到你要输入的用户名密码。。。但是，我理解的是，这次这样的 ...
他的解决方案需要在客户端第二次解码
看起来很美，但是在现在https的大环境下，这个需求并不大
在之前有网络被抓包的可能性，二次解码可以防止在网络上被盗
现在这个仅仅作为在本地第二次解码验证，在绝大多数服务器端没有这么弱智的问题的情况下几乎没有意义
另外zpvip很固执的认为到客户端的是明码所以服务器上的也是明码，所以服务器被盗或者被攻破就有泄漏的问题，我不知道他这逻辑是哪里来的
allesegal 发表于 2013-11-7 11:32
呃。。。我好像也没理解错。。是这个意思是，字符串是匹配验证账户有效性的，那这次的不就等于说是服务器 ...
这就是我说他这个看起来很美好但是不实用
他非要固执的认为，别人不支持他一定是没看懂，一定不是学info的，否则看懂的人怎么可能不支持，应该赶紧撒花啊
他的流程是
用户在登录以后，提交pw，服务器保存salt，验证F(pw, salt) ? 预设值
服务器端保存G(info, pw)
登录以后传输G(info, pw)
本地 ～G(G(info, pw), pw) = info
一般的服务器，在现在https大环境下不需要这么麻烦
服务器保存 g(info)----这年头没哪个服务器保存明码，除非是非敏感数据
传输的时候在已经登陆的情况下，直接发info过来
本帖最后由 allesegal 于 2013-11-7 11:41 编辑
shrek_munich 发表于 2013-11-7 11:33
他的解决方案需要在客户端第二次解码
看起来很美，但是在现在https的大环境下，这个需求并不大
在之前 ...
对啊，这不就是还是跟客户端联系上了，也就是说你还是得在客户端再输入次密码或者是你的客户端必须是特定的那个才行，但是人家的功能不就是密码都记录在服务器上了，自动填啊。。。
我理解的这次搜狗的bug是一个人用他搜狗的密码登录了浏览器，结果服务器就激动了，把不管是不是他账户里面的其他网站登录状态都发他那里去了，也就是说他可以在他浏览器里面以别人的身份访问被记录的网站。。。那搜狗也没告诉他别人的密码到底是啥，只是就让他登录着的而已。。。
allesegal 发表于 2013-11-7 11:40
对啊，这不就是还是跟客户端联系上了，也就是说你还是得在客户端再输入次密码才行，但是人家的功能不就是 ...
你登陆的时候不是输入过一次密码了么....
这decode过程在客户端后台就可以做，你看到的是decode以后的、
sogou这个bug应该和你猜测的差不多，不过我觉得是sogou在处理意外终止的时候recovery算法有问题
比如A在登录以后拿数据的时候突然断了，第二次再连的时候不知道为什么就自动recover成所有用户，然后下载线程就给你全拿下来了
表单数据是和网站挂钩的，比如你登陆taobao就会提示你taobao的表单，那么你知道的...
shrek_munich 发表于 2013-11-7 11:42
你登陆的时候不是输入过一次密码了么....
这decode过程在客户端后台就可以做，你看到的是decode以后的、 ...
对的对的，俺就是这个意思。。。我说的再输入次密码是指登录其他网站的密码，不是说登录搜狗账户。。。说的真够绕的。。你这个recovery的说法很清楚了，俺就是这个意思。。。这样的话哪管加不加密，只要不是跟某个客户端绑定就全部都有了啊。。。根本不用纠结我到底是知道不知道那些密码嘛，反正不用我输入。。
shrek_munich 发表于 2013-11-7 11:37
这就是我说他这个看起来很美好但是不实用
他非要固执的认为，别人不支持他一定是没看懂，一定不是学info ...
他说的比你这里写的还要复杂。
用户输入 pw, 服务器提供固定salt和随机challenge。本地计算 H2(H1(pw, salt), challenge) = token, 发送token。
服务器存储的是H1(pw, salt), 配合之前生成的随机challenge，也计算token，然后检查用户发送的token是否匹配，如匹配则设置登录。
然后用户上传的敏感数据info都是 G(info, pw)加密的。服务器从头到尾都不知道pw是什么。登陆后原封不动发送G(info, pw).
本地用 ~G( G(info,pw), pw ) 解码使用。
firefox就是这样的架构。
如果出现sogou这样的服务器bug，导致G(info, pw)发给了不相干的用户，其它用户没有pw，就无法解码
moudy 发表于 2013-11-7 11:53
他说的比你这里写的还要复杂。
用户输入 pw, 服务器提供固定salt和随机challenge。本地计算 H2(H1(pw, ...
我说了，这里最大的问题在于，pw如果丢失，所有的G(info, pw)变成死数据
他非要和我纠结G(info, pw)的效率.....
另外我这里有一点，challenge本身无非是单纯的增加了复杂度导致暴力破解不能，即使只用H1，发送H1(pw,salt)，在目前的复杂度下我也没有看出暴力破解的太大机会
zpvip 发表于 2013-11-6 16:57
同步就可以，
打开新电脑，用户名密码发到服务器，查用户表，发现密码经md5+salt处理后和服务器上的一 ...
看到这里稍微明白点了，那这次搜狗的问题来说，问题大概出·在设定用户为登录状态，把数据表打包下载·这个过程上，下载成别人的数据表了，那如果按照你的办法数据表是加密的，到客户端在用用户前面输入的密码解密，那就解不了别人的表。。。大概明白了~~上两道锁。。服务器等于保险柜，数据表是放里面带锁的包裹，登录好了等于开了保险柜，包裹拿到手，拿错了，钥匙不对也打不开。。。
allesegal 发表于 2013-11-7 12:02
看到这里稍微明白点了，那这次搜狗的问题来说，问题大概出·在设定用户为登录状态，把数据表打包下载·这 ...
这个比喻不错。