目前有没有用密码登录的网站做了前端加盐加密？

[whileFalse]

后端再次加盐加密。确保服务无法拿到用户明文密码。

[t6attack]

明白 LZ 的意思。明文密码 /可逆加密密码 不发往服务端。从根本上杜绝网线之外的人拿到用户明文密码。
作为用户，我当然希望这样。作为网站方，我不会这么干。

[geelaw]

@whileFalse #0 防止服务拿到密码，我看不出来意义何在。如果你相信前端的代码，则你可以信任这个公司不会偷你的密码；如果你不相信但又不得不用，使用一个随机密码。

@helone #3 这个解决方案是错误的。

@nfroot #17 对于病毒，我想是可以做绝的；对于企业，答案是不要在你公司控制的网络下使用个人账户。没有用就是没有用，不要给自己安全的假象。

前端加盐的结果是，用户实质上的密码变成了加盐结果，而不是用户输入的东西（攻击者可以直接发送加盐之后的结果）。
前端加密属于多此一举，这是用 HTTPS 做的。此外，好的实践是后端拿到密码之后验证身份，然后把身份信息从 用户名+密码 变成后端代码认可的不含密码的对象（标识符等），而不是继续携带密码传入更深的业务逻辑（楼主所说的“服务”）。

这类似于登录 Windows 之后，程序使用用户的 token 而不是用户的 用户名+密码，因为程序的环境受 Windows Local Security Authority 的管辖，只需要相信 LSA 即可——具体业务逻辑受后端控制器的管辖，只需要相信控制器的身份验证部分决定的结果即可。

[whileFalse]

@geelaw 从公司层面，可以装个 X 顺便防止内鬼或像 Github 那样的失误。

你知道有数字货币交易所拿自己用户的密码去别的交易所撞库吗？虽然这手可能不是内鬼，而是高层干的

[maichael]

@nfroot #17 但问题是每一项的安全措施都不是没有代价的。

[whileFalse]

@maichael 这个措施的代价高吗？

对于前后端程序来说，两小时够不够？
对于用户来说，如果用户先输入用户名，再输入密码，则用户体验不会有任何损失。如果用户使用密码填充软件，会多等一个请求，0.2 秒吧。

[zpf124]

@whileFalse 所以采用 sha256 或者更高级的摘要算法不就好了。
后端既然能知道盐，那自然也可以找加盐的彩虹表啊。


而且后端向前端发盐值，那这个盐和没加一样。
后端推荐加密 带 盐值，同时也建议不要使用统一盐，为的就是不让别人知道具体的盐值是什么，你盐都发给前端了，那加盐的更没意义。

[whileFalse]

@zpf124 建议去研究下盐的本质。盐本来就是可公开的。不使用统一盐的唯一目的是为了防止有人为了特定的盐作出彩虹表。就是说，防止被团灭。只要每个人的盐不一样，盐就起到了作用。

为了防止后端发来的盐是一个已经打了彩虹表的盐，那么可以这么做：盐是一个包含用户名自身的字符串。这样前端可以证明盐是足够复杂的。

[MonoLogueChi]

可能有意义吧，我以前搞个一个前端加盐加密再截取传输到后端，然后后端再加盐加密严重，个人感觉是不太可能用彩虹表逆推出来，即使从数据库里可以逆推到前端传输过来的数据，但是前端传输过来的数据已经是被截取过的，用被截取的数据去推完整的数据应该不太可能吧。

关于加密这方面我一点都不懂，根据个人臆想来做的

[nfroot]

@geelaw 对于你说的"攻击者可以直接发送加盐之后的结果"认真看内容啊，你没理解就自己设计破解方法了，太长我就简化下，你确定坏人能拿到我的数据重新提交？你随便提交，验证成功算我输！


服务器开启 https

post 下面几个数据给服务器
用户名
当前时间
随机值
sha256(用户名+sha256(密码）+当前时间+随机值)

服务器
判断客户端发来的时间是 60 秒以内
判断随机值不是在 60 秒或者更长时间内使用过
以上两个条件通过后，进行和客户端一样的计算，如果服务器存储时加盐了，客户端发送前要获取盐值

对比两个值是否一致，一致便通过，在 session 变量记录客户端 IP。每次客户端执行动作的时候判断 IP 是否一致。session 要有过期机制。


如果客户端提交的数据被再次提交，你试试能不能通过服务器的检查！不能吧？

只有两种可能破解
1.session 失效前另一个局域网的电脑偷取 cookie。和 UA 之类的浏览器标志，代替用户操作。
2.手段达到能随意修改用户页面，这个就不用讨论了。

同样还有更好的办法，比如
二次验证。
前端只提交用户名，提交后服务器将验证码发邮件或短信或微信通知用户，用户输入验证码完成登陆
客户端插件、软件防护
客户端插件简单的可以由浏览器插件实现，也可以用应用程序实现，用插件去预先获得一个客户端 ID 和密码(用来标识客户端)，使用插件完成计算过程。使用客户端密码去计算用户信息比如 sha256 或者自己的加密算法并完成登录。软件防护就是监控这个网址的代码是不是被修改了。

这应该是市面上可以实现的绝大部分方法了。

但是这仍然不是绝对安全的，应用程序和操作系统都是可以逆向的。




至于"不要在你公司控制的网络下使用个人账户"，这个只是说说而已，我们在给用户培训时说了一千遍一万遍，你觉得他们会听吗？密码 123456 的还少吗？所以我认为我们只能尽可能一步步去完善安全措施，降低用户出现损失的可能。


但是基于条件限制，我们不可能做到所有，所以我上面的回答也仅仅是因为很多人觉得没有意义，连程序员都觉得没有意义，用户又会在意什么呢？ 123456，abc123，Abc123，当然是怎么简单怎么来。。

[nfroot]

其实越想越和大公司差不多了，大公司能力强，会加入更多的因素，但是我认为还是有必要在能做到的条件下做到极致，反正这个东西一次设计能用很久的。


注重安全不是什么坏事啊。

[geelaw]

@nfroot #29 之前没有针对 #7 回复。你在 #7 的设计不能被总结为“加盐”，而是一种 TOTP。此外，无论怎样做都需要在设置密码的时候传输密码。

> 我们在给用户培训时说了一千遍一万遍，你觉得他们会听吗？

技术不能用来解决人的脆弱。

Minor pick:
> 只有两种可能破解
话不要说太满，请使用形式化的方式论证。