用户密码是在前端加密后传输给后端保存 还是?

[gebishushu]

还是先传输再到后端加密存数据库呢?

2 个方式有啥优缺点没?

[xmumiffy]

前段后端都做 hash

[chotow]

贴一下前两天在另一个帖子下回复的内容……

前端做校验，并在 UI 层限制弱密码。
以哈希值的形式提交密码密到后端，可以避免后端环节中的明文泄漏（比如日志），并增强用户对服务的信赖度。
除非有不可抗拒因素，否则必须使用 HTTPS 。

用户端哈希，优点是可以避免明文密码在服务端出现，缺点是服务端无法判断是否是弱密码。
如果我是用户，我更信赖用户端哈希的产品。

[tool2d]

这是 10 几年前 mysql 的上古协议，那时候很多协议都是明文传输，SSL 加密还没有开始大面积普及，客户端密码加密就成了关键。

我觉得至少在密码传输上，mysql 做的挺好的。

[chotow]

补充一下，用户端哈希过，不代表服务端就不需要再次哈希。
服务端哈希是必须的，用户端哈希是推荐的。

[ysc3839]

服务端 hash 是必须的，而且建议使用 argon2 等强 hash 算法。
客户端也推荐算一次 hash ，用于避免用户隐私泄漏，可以使用 md5 sha1 等弱 hash 。

[gebishushu]

@chotow
@ysc3839
@xmumiffy 感谢各位答疑解惑
明白了,我两边都做加密

[cat]

虽然楼上说的确实都有道理，可是，比如 GitHub 之类的网站为啥都是将密码明文传给后端呢 🤔

[tool2d]

@cat 可能 github 老板的癖好，就是收集用户各种明文密码。

[kabob]

我去年也有开贴问。里面的回答还挺多种角度的，可以参考一下： https://www.v2ex.com/t/854741

[lisxour]

@cat 可能是对于 https 来说，明不明文没啥大区别吧，一般都是登陆时向服务器请求临时公钥，rsa 加密传给后台，后台私钥解密得到密码，然后进行 hash 比对。

[yinmin]

@cat @gebishushu 商用系统一般都是启用 https 后传输明文密码（由 https 保护），服务器获得明文密码后加盐 hash ，然后保存到数据库的。

[DivineRapierH]

以下节选自 https://crackstation.net/hashing-security.htm

In a Web Application, always hash on the server

If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?

Even if you are hashing the user's passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users' passwords in the user's browser without hashing the hashes on the server. To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users' passwords are never sent to the server, but it's not.

The problem is that the client-side hash logically becomes the user's password. All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.

This isn't to say that you shouldn't hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:

- Client-side password hashing is not a substitute for HTTPS (SSL/TLS). If the connection between the browser and the server is insecure, a man-in-the-middle can modify the JavaScript code as it is downloaded to remove the hashing functionality and get the user's password.

- Some web browsers don't support JavaScript, and some users disable JavaScript in their browser. So for maximum compatibility, your app should detect whether or not the browser supports JavaScript and emulate the client-side hash on the server if it doesn't.

- You need to salt the client-side hashes too. The obvious solution is to make the client-side script ask the server for the user's salt. Don't do that, because it lets the bad guys check if a username is valid without knowing the password. Since you're hashing and salting (with a good salt) on the server too, it's OK to use the username (or email) concatenated with a site-specific string (e.g. domain name) as the client-side salt.

[xdeng]

前端 hash(p,s) ---h,u,s---> 后端存 h,u,s

[wu67]

有 https 其实问题不大, 直接明文传就行.

另外上面说限制弱密码的, 我劝你不要多管闲事, 就是这种事干多了, 才会整出那种需要同时包含数字大小写字母和特殊符号的变态强制强度密码

[whileFalse]

@chotow 信人不如信己，直接上密码生成器比较好