阿北能不能看到我在豆瓣的账户对应的密码？

完全可以。
无图无真相。我们先来看看豆瓣登录界面。

豆瓣的登录位置有好几个，在哪登录都无所谓。问题是当你点击登录按钮后，你的登录密码未经任何变换，直接以明文提交到服务器上的。为了证明这一点，我们尝试登录，然后用fiddler捕获一下请求过程，如下图。

当然，因为我输入的是假的密码，所以登录失败了。但是从 fiddler 上我们可以清楚的看到密码 12345678 就这么乖乖的躺在那里。

这意味着什么？
这意味着只要豆瓣愿意，它可以在服务端记录下你的原始密码。不管最终它是否会将你的密码以哈希或加密方式存储，但至少，豆瓣有机会知道用户登录密码的明文。

豆瓣为什么要这么做？
首先，对于豆瓣来说，你的帐户的所有信息，它都可以在不需要密码的情况下进行任意的修改，所以豆瓣对用户的密码其实并不感兴趣。其次，豆瓣确实会将用户的密码哈希变换后再存入数据库，用于一定程度上防范黑客直接获取到用户的明文密码。但是由于问题问的是“阿北能不能看到我在豆瓣的账户对应的密码？”，阿北回答不能。通过上面的分析我们知道，不是不能，只是不愿意而已。如果豆瓣需要，随时可以拿到活跃用户的明文密码。

如何改进？
在进行下面的讨论之前，我们必须提醒大家，豆瓣在登录验证的部分已经采用SSL加密来保护了，上面描述的问题并不是在暗示大家“豆瓣不安全”（安不安全是另外一个问题了），这里要讨论的是，虽然阿北声称无法看到用户的明文密码，但是我们通过简单的技术分析已经可以明确阿北在技术上依然可以轻松的看到用户的密码，并且用户无法知道。
我现在想知道的是，到底有没有一种办法，可以让阿北可以坦荡的向用户拍胸脯保证绝对看不到用户的明文密码，并且在技术上来说这种保证是可靠的——任何人都可以在客户端进行验证确保其没有作弊？

事实上这样的方案是存在的。
具体方案：基于哈希+HTTPS
当用户注册和登录时，用户的密码不会被通过网络直接发送明文，而是先经过哈希后再发送，并且发送时采用 HTTPS 加密。这种方案的核心在于，哈希运算是在客户端完成的，因此服务端接收到的用户密码都不是明文，阿北确实可以拍着胸脯说不会看到用户密码。由于中途通信加密了，安全性看起来还不错。但是我们也注意到，如果没有 HTTPS 的保护，这种方案非常容易遭受重放攻击。这一方案在业内可以说已经算常识了。大多数稍微有点安全意识的开发人员都知道。
网站需要用https访问就需要部署SSL证书。
SSL证书专业提供商：沃通（WoSign）CA:  http://www.wosign.com/index.htm
国产SSL证书和国外SSL证书对比：http://www.wosign.com/about/WoSign_ForeignCA_compare.htm

这工具好，居然可以看到密码。看来不部署数字证书的站点危险了。

部署数字证书加强网络安全很重要啊

豆瓣登陆有个同样严重的问题，就是登陆之后的跳转用的是302重定向，应该用303重定向。区别是登陆提交用的是POST，303可以强制浏览器访问目标网页的时候用GET，这样下次请求就不会含有原表格中的内容。但是302，浏览器可以用POST（带上原内容），也可以用GET，两种都完全符合标准。遗憾的是豆瓣虽然登陆提交用的是HTTPS，但他们接着302重定向到了非加密的HTTP页面，也就是说此时浏览器可能会带着用户名和密码一起访问非加密页面，给中间人提供机会。换句话说，对部分浏览器来说HTTPS用了白用。当然最好是全程加密，最安全，而不是登陆后立刻跳转到HTTP。

更新：我上面说的有点言过其实了。用302没有实际上的危险，我被IE的开发者工具误导了，以为IE会在收到302之后继续用POST，实际上IE也是会用GET的。当然从标准的角度看我觉得还是用303比302好。不过，全程加密，想用啥都安全。

helloworld 发表于 2014-9-24 14:27
豆瓣登陆有个同样严重的问题，就是登陆之后的跳转用的是302重定向，应该用303重定向。区别是登陆提交用的是 ...

是的，最好是全程加密。