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

[jybox]

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

[est]

用不着散列。再原密码后面随机加上一定字符再POST即可。服务器验证密码先去掉随机添加的字符，再验证。每次添加的字符和长度都随机。中间人拿到也是白拿。除非多次捕获。

[nigelvon]

@est 他可以拿到用户获得的表单页面，加上用户POST出去的内容就可以解出密码了，除非在客户端做非对称加密。

[est]

@nigelvon 好像也是。那么只能客户端散列了。不过客户端散列也没法避免重放攻击。所以还是得想个变化的方案。

我是记得很多嗅探密码工具只会修改form POST里面password passwd pwd关键字的。稍微变化一下可以避免这种无脑嗅探。

如果被单个盯上了。那么基本是跑不掉了。 T_T

[printf37]

选择一种非对称加密算法F
注册的过程使用SSL

用户注册时：
在本地浏览器中，仅以用户名和密码为种子（不得引入其它熵来源）生成n个随机数
用这些随机数生成F的一对密钥
把公钥发送至服务器

用户登陆时：
首先提交用户名
服务器使用该用户的公钥和算法F加密一串随机数和当前时间发送至客户端
客户端重复注册时的密钥生成逻辑，在本地生成私钥
用私钥解密得到随机数，验证服务器端时间
将随机数附上当前时间和验证码答案再用私钥加密发送至服务器
服务器用公钥解密，检查随机数、客户端时间、验证码答案
放行

随便YY的，不知道行不行

[dndx]

@printf37 既然都用 SSL 了，不如全程 SSL 。关你什么算法，没有 SSL 保护直接向页面注射一段 JS 发送击键事件就跪了。

[ipconfiger]

https不買證書一樣會被中間人攻擊的

[depr]

@dong3580 我也做过类似的设计，但是这样的问题是 C1 这个 token 如果被 http 嗅探到的话，那么攻击者可以获得完全的权限，因为服务端只通过这个 token 来识别用户身份，而且还没有类似于 web 端，让 session 失效的功能。我打算为此再配备 https ，放置 token 被嗅探，同时在后端可能要追踪一些特殊情况，比如异地登陆，长期不登陆之后再次登陆等异常现象，然后给用户发送一些提醒邮件。