完全可以。
无图无真相。我们先来看看豆瓣登录界面。
豆瓣的登录位置有好几个，在哪登录都无所谓。问题是当你点击登录按钮后，你的登录密码未经任何变换，直接以明文提交到服务器上的。为了证明这一点，我们尝试登录，然后用fiddler捕获一下请求过程，如下图。
当然，因为我输入的是假的密码，所以登录失败了。但是从 fiddler 上我们可以清楚的看到密码 12345678 就这么乖乖的躺在那里。
这意味着什么？
这意味着只要豆瓣愿意，它可以在服务端记录下你的原始密码。不管最终它是否会将你的密码以哈希或加密方式存储，但至少，豆瓣有机会知道用户登录密码的明文。
豆瓣为什么要这么做？
首先，对于豆瓣来说，你的帐户的所有信息，它都可以在不需要密码的情况下进行任意的修改，所以豆瓣对用户的密码其实并不感兴趣。其次，豆瓣确实会将用户的密码哈希变换后再存入数据库，用于一定程度上防范黑客直接获取到用户的明文密码。
但是由于问题问的是“阿北能不能看到我在豆瓣的账户对应的密码？”，阿北回答不能。通过上面的分析我们知道，不是不能，只是不愿意而已。如果豆瓣需要，随时可以拿到活跃用户的明文密码。
如何改进？
在进行下面的讨论之前，我们必须提醒大家，豆瓣在登录验证的部分已经采用SSL加密来保护了，上面描述的问题并不是在暗示大家“豆瓣不安全”（安不安全是另外一个问题了），这里要讨论的是，虽然阿北声称无法看到用户的明文密码，但是我们通过简单的技术分析已经可以明确阿北在技术上依然可以轻松的看到用户的密码，并且用户无法知道。
我现在想知道的是，到底有没有一种办法，可以让阿北可以坦荡的向用户拍胸脯保证绝对看不到用户的明文密码，并且在技术上来说这种保证是可靠的——任何人都可以在客户端进行验证确保其没有作弊？
事实上这样的方案是存在的。
具体方案：基于哈希+HTTPS
当用户注册和登录时，用户的密码不会被通过网络直接发送明文，而是先经过哈希后再发送，并且发送时采用 HTTPS 加密。这种方案的核心在于，哈希运算是在客户端完成的，因此服务端接收到的用户密码都不是明文，阿北确实可以拍着胸脯说不会看到用户密码。由于中途通信加密了，安全性看起来还不错。但是我们也注意到，如果没有 HTTPS 的保护，这种方案非常容易遭受重放攻击。这一方案在业内可以说已经算常识了。大多数稍微有点安全意识的开发人员都知道。
网站需要用https访问就需要部署SSL证书。
SSL证书专业提供商：沃通（WoSign）CA