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
看到这里稍微明白点了，那这次搜狗的问题来说，问题大概出·在设定用户为登录状态，把数据表打包下载·这 ...
这个比喻不错。
shrek_munich 发表于 2013-11-7 12:00
我说了，这里最大的问题在于，pw如果丢失，所有的G(info, pw)变成死数据
他非要和我纠结G(info, pw)的效 ...
G(info, pw)死了就死了，还是那句话，敏感数据宁丢勿漏。
先提到G(info, pw)和~G()效率的是你啊，而且确实没说到点上。
另外challenge的作用不是增加复杂度，而是对抗网络抓包。不然别人想办法抓到你的token，就可以登陆了。而配上随机challenge，每次的token都不一样。
本帖最后由 shrek_munich 于 2013-11-7 12:11 编辑
moudy 发表于 2013-11-7 12:07
G(info, pw)死了就死了，还是那句话，敏感数据宁丢勿漏。
先提到G(info, pw)和~G()效率的是你啊，而且 ...
我说的是，如果可逆的话，decode+encode的效率.....
https下抓包问题应该已经在协议层解决了吧
我重新回去看了原文，我说的是
如果更改密码，所有数据无效，这里的无效是死了啊
他就给我理解成，有老密码，decode+encode，然后就开始鄙视我不知道加密效率，我说，我带863的时候不知道他上大学了没
我说他自以为是很过分么，你仔细看清楚我的帖子，别被他自言自语误导了好吧
moudy 发表于 2013-11-7 12:07
G(info, pw)死了就死了，还是那句话，敏感数据宁丢勿漏。
先提到G(info, pw)和~G()效率的是你啊，而且确实没说到点上
回帖支持表示你不是我的马甲，
回复太精彩了！
shrek_munich 发表于 2013-11-7 12:00
我说了，这里最大的问题在于，pw如果丢失，所有的G(info, pw)变成死数据
他非要和我纠结G(info, pw)的效 ...
他的意思就是pw不能丢，丢了活该，士可杀不可辱，丢了那就只能自己重新再去另外建个g（info，pw）。。。纯提问，这个pw没丢的情况下，应该也是可以改吧，自己把自己绕昏了。。应该是能改吧。。。{:5_355:}
爬完楼终于搞搞明白了。。。我真是闲的。。。
moudy 发表于 2013-11-7 11:53
他说的比你这里写的还要复杂。
用户输入 pw, 服务器提供固定salt和随机challenge。本地计算 H2(H1(pw, ...
你这个解释的最清楚了。。。{:5_370:}
allesegal 发表于 2013-11-7 12:24
他的意思就是pw不能丢，丢了活该，士可杀不可辱，丢了那就只能自己重新再去另外建个g（info，pw）。。。 ...
当然能改，呵呵，不是 info 的都理解得这么透彻
shrek_munich 发表于 2013-11-7 12:08
我说的是，如果可逆的话，decode+encode的效率.....
https下抓包问题应该已经在协议层解决了吧
呃。。。大概是这个"如果更改密码"引起歧义了吧。。。我开始也理解成是有老密码去修改成新密码。。。。{:5_333:}
zpvip 发表于 2013-11-7 12:26
当然能改，呵呵，不是 info 的都理解得这么透彻
我可以理解为
作为设计者，我都已经点名了丢失密码可能无效，你难道自己都没有意识到如果没有老密码，数据会死么？这都理解错我能够认为你考虑的时候根本没有把这种情况考虑进去么？实际上用户忘掉密码并不是什么新鲜事
本帖最后由 zpvip 于 2013-11-7 14:28 编辑
中午吃了顿畅快饭。
我很久不用firefox了，看了一下，firefox现在也支持 master password 了，不过跟 lastpass 一样，忘记了就惨了，数据全丢。
https://support.mozilla.org/en-US/kb/use-master-password-protect-stored-logins
https://support.mozilla.org/en-US/kb/reset-your-master-password-if-you-forgot-it
OS X FileVault 2 的密码也不能丢
http://support.apple.com/kb/HT4790?viewlocale=zh_CN
Roboform 填表的也不能丢Master Password
http://www.roboform.com/tutorials/reset-master-password
Keepass 的 Master Password 也不能丢
http://keepass.info/help/base/keys.html
1Password 也一样
http://learn.agilebits.com/1Password4/iOS/Tutorials/ios-forgot-mp.html
lastpass 和 wuala.com 就更不用说了
好像全天下管敏感信息的，只有搜狐是特例，没有 master password
另外，给dropbox做各种加密的软件或在线服务，也不允许用户忘记密码
https://www.boxcryptor.com
http://www.techbang.com/posts/12603-dropbox-cloud-sync-encrypted-files-important-data-releases
http://www.truecrypt.org/faq
allesegal 发表于 2013-11-7 12:02
看到这里稍微明白点了，那这次搜狗的问题来说，问题大概出·在设定用户为登录状态，把数据表打包下载·这 ...
但是如果我告诉你，一旦你自己的钥匙丢了，那么包裹里面的东西就得全部销毁，那么你是不是就要开始琢磨是不是继续把包裹存在我这个保险柜里面了？
zpvip 发表于 2013-11-7 14:19
中午吃了顿畅快饭。
我很久不用firefox了，看了一下，firefox现在也支持 master password 了，不过跟 la ...
http://finance.ifeng.com/a/20130808/10381920_0.shtml
赶紧和chrome说吧，没准google赏你个安全经理当当哦
mymy365 发表于 2013-11-7 14:19
但是如果我告诉你，一旦你自己的钥匙丢了，那么包裹里面的东西就得全部销毁，那么你是不是就要开始琢磨是 ...
你真可以不用，但用的人也很多，就像我例出来的那些例子，这还只是一小部分：
http://www.dolc.de/forum.php?mod=redirect&goto=findpost&ptid=1682012&pid=33644750&fromuid=24096
zpvip 发表于 2013-11-7 14:30
你真可以不用，但用的人也很多，就像我例出来的那些例子，这还只是一小部分：
http://www.dolc.de/forum ...
你就没有想过，为什么dropbox自己不提供这样的功能而需要通过第三方提供
同理chrome，google自己不提供这样的功能，你愿意你可以通过第三方插件实现
zpvip 发表于 2013-11-7 14:19
中午吃了顿畅快饭。
我很久不用firefox了，看了一下，firefox现在也支持 master password 了，不过跟 la ...
特例？你没发现的多着呢。
。。。
到今天，我自己做个总结，最后说一下吧：
作为提供一个信息，我的主要意思还是做一个一般意义上的安全意识普及，如果你很喜欢使用国产软件，那么你就应该做好你的个人信息被泄露的心理建设。
所以只要你还没有被扒光衣服，就已经可以开心的笑了。
QQ不收集隐私？360不收集隐私？微信，微博，你用的哪个是安全的？就算在德国，哪有绝对的隐私。你的银行账户，人家美国老大哥，随时可以随意查看。
这是一个一般意义上的讨论。我们只能从各个方面尽可能的小心，但是做到完全避免是绝对不可能的。
总结完了，然后是给你的话。我不知道你质疑慕尼黑的意义何在。我还是那句话，你可能学了一些安全的基础知识，但是这不是这里要讨论的主题。当我看到你在说MD5的时候，我就已经笑了。这里是个论坛，大家根据一些主题，做一些交流。这里不是一个Party，如果你对某方面话题，没有太多内容可说，你可以保持沉默，听听大家的。但是你不是需要在每群人的交谈中，都极力想把话题带到你擅长的地方，想要成为焦点。
就像我说的那个比喻，我们只是想讨论羊肉怎么烧，就算你觉得你海鲜是你的拿手菜，但是我们并不感兴趣。
你让我想到曾经的一个感觉，就是：本科生写论文，总会在Introduction一些能写个几十页。但一旦你学的越多，你就会发现其实Introduction有时候很难写，需要一定的字数，但是你会觉得每一句其实都是废话，因为能阅读你这个Paper的，一定都知道这些破理论。
所以我也一直在说，需求，需求。我的意思是告诉你，虽然你学到的方法，你掌握的方法从某个角度有一定的优点，但同样也会带来弊端。所以一定要根据用户的主要需求来决定怎么做。比如我们可以讨论说，搜狐如果给用户多一点选择，比如允许用户自己设定加密方式，自己决定宁死不屈还是要在任何情况下都能找回信息。但即使真这么做，也仅仅是针对一些高级用户。你所说的lastpass之类，都不过是很小众的东西，别不服气，你要接地气，你要知道用户需要什么，提供他们所需要的，而不是把你认为好的强力推销给它。
再到后面，已经很可笑了，开始从注册年龄开始讨论专业与否，再下去是不是都要得掏身份证了？这就已经严重偏离主题了。
PS：就像你猜测慕尼黑一样，我也一直猜测你最多只是个学计算机科学的，你也没有回应，不知道是不是说对了。写程序和Info尤其是安全，其实还是有很大差距的。尤其是理论的东西。所以你觉得好强大的东西，其实并没有你想得那么强大。同样的，你也不用猜测我是干什么的，干了什么，见了什么样的客户，有什么样的项目。最后就问一个问题： 你写过这样的考试么？ 两个小时，一张纸一支笔，一个字符串，把MD5码写出来，写出来就过，写不出来就挂。
或者一个字符串，选一种方法，比如AES，参数选定，然后让你把第8轮的结果写出来，写不出来这门就算挂～～～
这些其实都已经算是偏实际的小测试了。。。
mymy365 发表于 2013-11-7 15:01
特例？你没发现的多着呢。
。。。
到今天，我自己做个总结，最后说一下吧：
这就是学生和业界的区别
学生觉得我读了xx技术，哇塞，好美好，大家都应该去用，不去用的都是老头子，都是不懂技术的，都没学过info，我永远只要管我能不能达到我的目的，而不管客户要什么，客户如果像猪一样笨怎么办
做产品的我永远要考虑，客户需要什么，尤其是客户不知道自己是猪一样笨的时候，我怎么让他觉得自己是神一样的存在
本帖最后由 zpvip 于 2013-11-7 16:32 编辑
mymy365 发表于 2013-11-7 15:01
特例？你没发现的多着呢。
。。。
到今天，我自己做个总结，最后说一下吧：
谢谢你给我打那么多字，我现在没时间详细回复，简单来说，我一直在强调敏感信息是不允许明文或有可能很简单就被解密的密文放在接入互联网的服务器上，这是一个程序员的道德底线。chorme 明文存密码，但人家不上传到服务器，如果上传到服务器，chrome也会加密 https://support.google.com/chrome/answer/1181035
我的所有信息都会被查看，但不包括我的各种密码，尤其是支付宝或银行密码。
如果你看一下这个链接就知道我为什么在回复他
http://www.dolc.de/forum.php?mod=viewthread&tid=1682012&page=1&authorid=217129
你换台机器怎么办？你这个密钥需要修改怎么办？你这个密钥自己忘记了怎么办？
我承认开始没说不能忘记密码，但前两个问号是很简单的。这是在我23楼用了例子解释之后，他提出来的问题。我后面问他是不是学 info 的，这也是原因之一。
你登陆那一刻，请问你如何验证密码？你还是要在服务器有一份的吧，同样面临泄漏的问题。
如果你只纠结在“假设”只有个人信息会泄漏，密码是“不会泄漏”的，那我请问你这两个难道不都是私有数据？
服务器是否加密并不影响结论，我才是觉得你确定你设计过网站么
这明显就不知道 lastpass 怎么运作的。
那个网站有这样的约定，用户密码不可找回？？！！
他认为不存在这种事！
请问salt就不是数据么，还是这个数据真特别啊，别的数据都会泄漏，唯有这个数据金刚不坏，永远不会泄漏滴
你认为他懂 salt 吗？ salt 和 hash 都可以泄漏，但用户密码是安全的，至少是相对安全的，不好意思，我知道你看我这句话就像我听一个不会广东话的人唱粤语歌
那么你每一次修改密码，你所有的用户数据都会无效
修改密码这么简单的事，他说数据都会无效
第一，你需要一个所谓的本地密码，这个不具有漫游性，回到原点
第二，你云端数据并没有密码，你也说了服务器不保存密码，这些数据就永久的变成死数据
这段话我就不说啥了。
对任何一个个体网站而言，我只要求你记一个密码，它并不知道也不对别的网站密码负责
至于你说插件形式解决，那就是我一开始说的第三方解决
如果你要对方解决，你的意思是sogou提供类似服务，以后各家网站的密码都要通过souguo encode和decode以后才能用么？souguo会很高兴提供这样的服务的，只不过你确定别家都愿意买它帐么
这段话我也不说啥了。
还有很多，你可以慢慢看
我也只是发表一下我的观点，评论一下搜狐的程序员在设计上有问题，是他找的我，说我没看明白发生了什么，我也解释了，知道是bug，不是服务器被爆了，但不能因为服务器不被爆就上传用户的密码到搜狐，搜狐这样做是道德问题。
另外，如果是你从开头看他的问题，你如果好心的话，会不会跟他解释一下？我其实是被动的，觉得他的理解有问题才去讨论。他有些问题到后面会有些解释，比如修改密码之类的，但我又不是先知，怎么可能他说错了，我还能知道其实他心里不是这样想的。
mymy365 发表于 2013-11-7 14:19
但是如果我告诉你，一旦你自己的钥匙丢了，那么包裹里面的东西就得全部销毁，那么你是不是就要开始琢磨是 ...
对啊，史莱克讲的也是这个问题。这个确实需要考虑的。而且，我觉得现在能放网上的东西都不是需要那样的保密级别吧。如果是可有可无的东西就不需要这样，如果是太重要的东西也不能去冒这样完全找不回来的风险。。。
我是从来不用表单记录。。。实在记不住的纯手动。。哈哈哈。原始人。。
zpvip 发表于 2013-11-7 15:53
谢谢你给我打那么多字，我现在没时间详细回复，简单来说，我一直在强调敏感信息是不允许明文或有可能很 ...
修改密码这段我后面注释过了，是如果你忘记密码的话数据无效
另外，这楼里mymy看懂了，moudy看懂了，包括那位不学info的看懂了，还就只有你这位"专业"人士非和我钻牛角尖
另外，工作原理人家看你的没看懂，看我和moudy的解释才看懂，这就是你所谓的别人啥都不懂么
allesegal 发表于 2013-11-7 15:56
对啊，史莱克讲的也是这个问题。这个确实需要考虑的。而且，我觉得现在能放网上的东西都不是需要那样的保 ...
打一个比方，不能细说，多说我就涉嫌泄密了
有一些东西很重要，需要云备份，但是有远远大于简单的表单数据
打个比方，宝马设计了一款新车，需要很多工程师云设计，要考虑安全问题不能泄露，同时要保证上传下载的效率，更不可以接受诸如忘记密码就要从头开发，而且这里还有一个问题叫做多用户同步。
shrek_munich 发表于 2013-11-7 16:06
打一个比方，不能细说，多说我就涉嫌泄密了
有一些东西很重要，需要云备份，但是有远远大于简单的表单 ...
明白，你说的这个例子听起来像需要更安全点的dropbox。。。{:5_310:}