大公司怎么还在犯这种低级的错误。我说的是tumblr

[neodreamer]

用户登录的密码是明文传输的。

小公司犯错还可以理解。大公司还犯这种低级错误就有点搞笑了。

http://m.newyorker.com/online/blogs/elements/2013/07/tumblr-vulnerability-how-to-secure-your-passwords.html

[Perry]

我只看他们犯错误后的态度

[neodreamer]

@Perry 事后态度很重要。但这么简单的措施不做是没想到日后成名，所以无所谓吗？

[juntao]

刚开始是实习生写的。后来没人改过这块代码了。。运行的好好的嘛。= =

[metalbug]

雅虎收了，应该会改吧？谁知道呢，反正也不碍事

[angryz]

感觉哪个公司都不能完全放心，还是得自己辛苦点做好安全防范。

[ejin]

大部分网站都明文传输的，另外换句话说，99.9999%的网站都是http协议，可窃听可篡改的，没几个人会https开头打网址，只要不是直接https打开，跳转也能改

[hutushen222]

除了HTTPS，怎么处理算安全的呢？

知乎上看到还有JS加密的方式，这个过程是指表单提交后，使用JS将密码变成可解密密文后传递给服务器段吗？
http://www.zhihu.com/question/20306241

[lichao]

@ejin 登陆页面强制 https 是常识

[hutushen222]

@lichao 这也分站点类型吧，比如V2EX的登陆页面就没有HTTPS。

[lichao]

@hutushen222 嗯，改一下，大型网站登陆页面强制 https 是常识

[pfipdaniel]

登录用https，登录完成后http，于是乎可以比较容易的劫持用户session

[linlis]

靠，太让人失望了，居然是 Tumblr，亏得我一直用的 Tumblr

[treo]

只要是http传输的，加密还是明文有什么区别

[treo]

@hutushen222 这个属于自欺欺人，如果攻击者可以嗅探到明文密码，那么同样也可以嗅探到js加密后传输的hash，replay一下，和拿到明文密码的效果是一样的

[notedit]

@hutushen222 不是传送的可以解密的 是hash值 所以服务端也不知道用户的密码是神马 具体的原理可以参考mysql的验证

[notedit]

@treo 参考我上条

[swulling]

@notedit 在没有https的情况下，这是一个不得已的办法，本地hash后传送

[hutushen222]

@swulling @notedit 我认同 @treo 的观点， HTTP协议下加密和明文没什么区别，嗅探到之后都可以用以登陆当前站点。

HTTP协议下加密的方式唯一的好处可能在于不能直接用hash串去登陆其他的站点。

[neodreamer]

@linlis 这次事件只影响 iPhone 和 iPad App 用户。web 登录用户不影响。

[luikore]

和公司大小没关系, 而且软件质量控制的难度是随着团队大小的指数增长的