用户注册时的密码安全性校验应该在前端还是后端完成？

关键词：非对称加密。

那你强制 https 呗...

脱离 https ，讨论泄密没意义。

@cwcc 额，一个注册没必要搞这么多次请求吧

2023 年了 https 还不是标配？
无论前端做还是后端不都应该上 https ？

前端校验。用户对自己的输入负责，自行设置弱密码对业务造成影响。

非对称加密就更好了，但都到这步了，为啥不上 HTTPS 呢？

@8355 想想保密项目，内网项目

前端校验, 弱密码才能方便用户. 安全性要靠自己来保证, 不要指望用户. 即便用户设置 123456 这样的密码, 也要能保证用户的安全. 可以配合用户常用 IP, 常用手机, 用户所在地, 用户大数据画像来确保用户安全, 不要靠强密码, 这会极大的降低用户体验.

最简单的方案就是前端 js 里面带上公钥，用 JSEncrypt 直接加密传到后端用私钥解密就行了。其他复杂的各种认证、密钥交换算法如果有兴趣也可以研究一下。总之为了加密而加密行不通，系统总有薄弱点，但加密传输目前容易做到的应该就是非对称加密和 HTTPS 通信了。

@githmb 那种项目根本就不需要做设置密码的功能，管理员密码只允许物理机本地修改（开变更单进机房改）

通过 https 送到后端校验。尽量部署 https 。

没有 HTTPS ，你这种前端加密没啥意义。

安全性校验 ，我理解应该是比如密码位数，是否大小写等规则校验，这个东西不是前端就可以么？为啥还要给后端

@githmb 如果是内网项目，让甲方出台制度，用户必须签署“我草忒马的虽然心里不爽但是既然组织上规定弱密码造成的安全事故责任自负了那我就乖乖执行我承诺我不使用弱密码如果我欺骗组织就天打雷劈”协议。

世间安得双全法，不负如来不负卿。你有不想让 geek 用户绕过前端的需求，又有不发送明文的需求，又不用 https ，又嫌非对称加密“一个注册没必要搞这么多次请求吧”……想啥呢？

@cwcc 这种内置公钥确实是一种好办法

@adoal 9 楼已有答案

在前端做校验就够了，如果用户可以强行设置弱密码，那就说明他有一定的技术能力，就不用担心他的安全性问题了。

@githmb #9 说的不就是#1 的具体实现？然而你在#3 里对#1 表示没必要，又说#17 里回复我的#15 比哦啊哦是#9 是答案……这是啥姿势？

加个 2FA ，安全性直接加一百倍

@githmb 保密项目和内网项目同样可以用 https 啊，自己内网生成一个 CA 证书就行了，内部设备都信任这个证书。

看不懂这帖子到底再讨论什么。

前端校验一遍，发明文给后端，后端再校验一遍能死？

不上 https 怪前端？

已经 2023 年了，还搞什么 JSEncrypt ，是嫌 TLS 不好用是吗？

> 没有 https 的情况下

这种情况不应该发生

前端加密没有意义，防不了中间人攻击。

没有 https 的话 前端传的是哈希值还是别的都不一样吗

不上 https 只带上公钥也不安全，即使是前端打包后的代码，密钥也是可以找出来的

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

那我问你，http ，你泄露了哈希值，我拿到不是一样能登录嘛？这有区别嘛？

密码的 hash 值如果被中间人截获，中间人随时可用此值进行认证，几乎等同于截获密码。若防止中间人截获，至少应该上 https ；再进一步，用非对称加密传输给服务器（当然公钥是否可信，会是另一个问题）。

检查弱密码，可以通过 hash 值碰撞测试。如果不用 hash 值，也不必传输密码原文，可在前端对密码进行随机变形，比如 abCDef123# 变成 hiJKlm456*，他们的安全性是近乎相等的。

@adoal 所以说我问的是懂的人，不是你这种人啊。人家一眼就能看出来我是嫌交换证书麻烦，还不安全。

两端都要，前端检验格式，后端排重以及不当字符

不用 https 前端花活再多都是白给. 我能想到的应用场景就是某些为了等保而等保的内网项目, 运维人员又不懂得怎么部署 https.

@lujiaosama 你是懂的，哈哈

@x2420390517 不一样，很多用户在多个网站用一个密码