设计 Web 站点的登录功能时，是否有必要将密码在前端进行一次散列再发往服务器

[jybox]

这样的好处：明文密码自始至终不经过服务器，避免了服务器运维失误出现泄露明文密码的情况(例如前一阵的 Heartbleed).

[ETiV]

QQ 的web登录就是这么做的

密码+验证码一起 hash 后再发出去

所有不需要手工输入验证码的地方, 验证码都是 ! 开头的.

[txlty]

避免不了的。登录凭证总会出现在服务器内存里（不一定是明文密码）。
客户端本来就该散列一下。即使需要获取明文密码，也该可逆加密一下。QQ就是RSA可逆加密，服务端有私钥可以还原出明文密码，中间人是抓不到明文密码的。

[dong3580]

@jybox
目前我的做法：
1,服务端保存方式 X = MD5(MD5(密码)+用户名)
2,客户端 C1= MD5(MD5(验证码)+MD5(MD5(密码)+用户名)))
3,客户端会发送 C1 和 用户名 到服务器
4,服务器 验证 C1 = MD5(MD5(验证码)+X)
说的很乱，楼主将就着看哈。
唯一不安全的地方就是注册的时候！
另外可以依照这个模式拓展加密的方法，小众加密一下，

[ibudao]

@txlty 貌似浏览器上的js还不能RSA加密吧。。

[jybox]

@txlty 我的出发点是『对用户而言服务器也是不应当信任的』，虽然服务器对登录凭证有完全的控制权限，但是对于『明文密码』这类隐私信息，不应当让服务器知道。

[jybox]

@ibudao https://code.google.com/p/crypto-js/

[txlty]

@ibudao 可以。QQ邮箱就是。
http://res.mail.qq.com/zh_CN/htmledition/js/qmlogin1c9135.js

[brickgao]

我觉得没有必要吧，如果有中间人攻击的话是可以篡改网页内容的。

[jakwings]

@jybox 这么说，就是只希望每次都用一次性密码，或者使用明文模糊后产生的不可逆密码，再经过 RSA 之类的加密方式传递到服务器，以求用户的「人性化密码」不被入库？

[dndx]

不可以，否则被脱裤散列起不到任何保护作用。黑客直接发散列就能登录。

[crab]

客户端提交时密码RSA公钥，服务端RSA私钥解密。可以防止监听抓包这些吧。

[tioover]

可以是可以，但是服务器要加盐二次散列

[dorentus]

「A false sense of security is worse than being unsure.」

[dndx]

@crab 不使用 SSL ，公钥也可能在传输途中被替换。

[chemzqm]

安全需求不是特别高可以学学weibo密码附加用户名的一部分字符做个base64，实现简单一些，也能部分防止中间人。可能你的项目黑客都没兴趣入侵，先不用想太多吧，真需要安全的话请用https。

[bitbegin]

使用公私钥加解密的是否所有用户都使用一对

[wy315700]

客户端散列没必要，因为如果遭到劫持，他可以把散列后的结果给你重放一遍

[wwek]

即便是 中间人攻击抓到了 散列后的密文 可以登录。
我们也需要散列加密。 怎么都比明文好·

[cdffh]

如果 从纯粹技术的的角度考虑 不想用https的话，还是散列一下比较靠谱。

[yyfearth]

@dndx 从系统的角度考虑是多余的 不能起到保护系统
但是从用户考虑 这样做至少可以保护用户密码原文

@cdffh 走https是必须的 不然中间人攻击 无法避免，大不了可以在html里面加script直接发密码原文，什么都防不了（就算是有CSP保护，中间人大不了可以把header拿掉再插script）
而js加密，可以避免用户密码原文泄露，就是heartbleed，也只能拿到hash后的结果，虽然仍然可以用来攻击系统，但是避免用户被社工