这是一个创建于 1724 天前的主题，其中的信息可能已经有所发展或是发生改变。
个人感觉不需要，因为前端已经校验过了，后端再做一次 equlas 判断感觉没什么必要，但是看到有些开源项目也把这个字段传到后端做校验？请问把这个再次确认传到后端起到什么作用？
 |
1
GaoGeYang 2020-03-10 10:44:06 +08:00
我觉得不需要，毕竟 js 发明的初衷就是在前端完成表单校验。
|
 |
2
Explr 2020-03-10 10:45:18 +08:00
我认为不需要，传到后端再校验一次会增大服务器压力。但是要考虑出于种种原因，前端校验代码没有正确的执行时，如何善后。
|
 |
3
nevin47 2020-03-10 10:46:14 +08:00
中间者攻击了解一下?
|
 |
4
murmur 2020-03-10 10:47:44 +08:00
不用的，只要做了非对称，上了 ssh 就差不多了，有些网站在输入密码时如果选择明文输入框打一次就够了
|
|
6
murmur 2020-03-10 10:47:57 +08:00
更正 ssh->https
|
 |
7
wunonglin 2020-03-10 10:50:00 +08:00  3
不会，确认密码这个只是防止他输错，并没有其他目的
|
 |
8
monospace 2020-03-10 10:51:48 +08:00
就这个场景来讲：不需要。退一万步讲，即便前端校验代码没有正确执行，最坏的结果是用户密码更新成了非期望值。这种情况一是几率很小，二是可以被接受的。
|
 |
9
delectate 2020-03-10 11:31:41 +08:00
其实现在有两个趋势：
1、不需要二次确认，只要输入一次即可； 2、用指纹代替密码。 还有个未来的趋势： 手误或者输入其他密码（如历史密码，其他网站通用密码），也可以顺利登陆。 这个有点抽象，解释一下：比如密码是 password，但是手指头抽筋输入了 pssswoed （对于移动设备，和可能的），后台在不保存明文密码的前提下，仍然可以识别并顺利登录。 目前来看，最好的这种方案是使用认证平台的统一登陆即可。。。 |
 |
10
wanguorui123 2020-03-10 13:23:17 +08:00
我认为需要，我的原则是不信任客户端。
|
 |
11
hand515 2020-03-10 13:25:41 +08:00
二次确认的目的是防止输入错误，并不是为了安全，所以不需要
|
 |
12
opengps 2020-03-10 13:44:17 +08:00
为了逻辑严谨，虽然前段已经经过了校验，但是对于后端不应该完全相信不过前段的。
所有逻辑都建议后端二次校验，因此我投需要的票 |
 |
13
freakxx 2020-03-10 13:49:30 +08:00
用户体验优化 感觉没必要去到后端再做一遍。
然后楼上解释原因，中间人攻击和逻辑严谨， 虽然这么说有些过分，但总的来说，还是有些像脱裤子放屁。 |
 |
14
183387594 2020-03-10 13:51:51 +08:00 1
我的原则是完全不信任用户,
用户传上来的密码肯定不是他想要的， 我把他的密码替换成 123456 后再告诉他🐶 |
 |
15
FallenTy 2020-03-10 13:55:35 +08:00 1
后端不能完全信任前端
|
 |
18
liuxey 2020-03-10 13:59:24 +08:00
不需要，如果一个密码能被替换或修改，那么两个也是一样的，除非做其他校验，所以单纯讨论楼主的问题就是：不需要
|
 |
19
Xusually 2020-03-10 13:59:36 +08:00
@nevin47 解释一下思路，中间人攻击在楼主这场景中，传不传"请再次确认新密码"字段，有和差别？
最多就是前端验证如果有问题，密码被设置为了非期望值。 在我看来，没看到"请再次确认新密码"字段有传到后端的必要，这个和信任不信任前端输入没有关系。 真是 MITM 攻击的话，能改你密码字段，同样可以改你"请再次确认新密码"字段，改成一样的有额外的难度么？ |
 |
20
HongJay 2020-03-10 14:00:11 +08:00
我的原则是谁都不信，就不应该使用我的密码，难道这种公司的数据库不会泄露吗
|
 |
22
LokiSharp 2020-03-10 14:08:50 +08:00
个人感觉。。。没必要“请再次确认新密码”
|
 |
23
dndx 2020-03-10 14:09:09 +08:00
不需要传两遍。实际上很多网站注册或者找回密码都不需要再次确认了，密码输错的毕竟比较低，这样体验反而更好。
|
 |
24
Airon 2020-03-10 14:15:52 +08:00
不需要传，后端只是保存密码后续登录时校验，再次确认只是为了用户确认密码是否是期望值。个人认为其实注册的时候让密码可见就可以省略再次输入了。
|
 |
25
julyclyde 2020-03-10 14:16:01 +08:00
前端兴旺年代啊新产生的问题
古代的时候，整个 form 都会提交的，根本不需要问 |
 |
26
MeteorCat 2020-03-10 14:17:00 +08:00 via Android
不需要，那个只是为了防止用户误操作或者输入错误再次请求
|
 |
28
kasper4649 2020-03-10 14:40:36 +08:00
刚去看了一眼 Twitter 和 Facebook 的，都把确认密码放在参数里了，至于后端用不用就不知道了。
|
 |
30
neilq 2020-03-10 14:56:50 +08:00
技术角度来讲是不需要的，但是不怎么信任客户端，前端知道自己做了验证，但是作为后端没法确认前端是否做了验证，又或者是有输入性 bug ？另外，也不会给服务器什么压力，多几个字节？本来也没几个人会一直改密码，恶意攻击就是另一回事了，少几个字节人家也能攻击。
|
|
31
neilq 2020-03-10 15:01:20 +08:00
开发很多时候不只是跟技术做斗争，而是在和人做都在，很多防御性变成思路，有一部分是为了，出 bug 时，便于扯皮
|
 |
32
darkbluever 2020-03-10 15:04:27 +08:00 2
需要考虑前端的代码是否能够正常运行，考虑极端情况比如用户可以在浏览器禁用 JS。如果前端代码在禁用 JS 的场景下通过提交表单把数据发到后端，这样就需要在后端做校验。
|
 |
33
KyonLi 2020-03-10 15:08:46 +08:00
有用，万一攻击者只伪造了密码而忘记伪造确认密码，不就防下来了嘛
|
 |
34
jzmws 2020-03-10 15:10:07 +08:00
这个是一个好问题, 首先明确一点的是,所有前端输入的都是不友好的, 重复输入前端完全可以做校验 . 作为一个后端程序员,我会让前端传. 所有数据后端校验才是安全!
|
 |
35
whoami9894 2020-03-10 15:12:42 +08:00 via Android
输两次只有一个目的：防止用户手误。前端校验一下两个 input 值相同就 OK 了。后端再校验一次的意义是啥? 咋还扯到 mitm 了
|
 |
36
icyalala 2020-03-10 15:17:39 +08:00
用 "不信任客户端" 或者 "中间人攻击" 做理由的，你就算输入两遍，人家中间人两个都改掉，那不还是没卵用？
数据安全是通信来保证的，输两遍不是为了安全，只是避免用户自己手误。 |
 |
37
ryanlid 2020-03-10 15:19:39 +08:00
不用
|
 |
38
HeiXiaoBai 2020-03-10 15:21:18 +08:00 via Android
设置重复密码的原因不是前端密码显示为*，然后怕用户输入密码错然后要重复输入一遍么，传到后端要用来干啥。
|
 |
39
no1xsyzy 2020-03-10 15:22:45 +08:00
原想说不需要的，想了想似乎是需要的……
考虑前端（不仅仅 Web ）如何校验密码无非这几种：1、当框内内容发生改变时； 2、当键盘被按下时； 3、定时。 注意前两种事件在 Web 端非常不友好：1 有可能意外不触发，2 触发机会额外高，容易导致卡顿。注意，尤其各种输入法（ Windows 下御三家姑且有密码框关输入法，但操作系统太杂）。无论是 3 还是 1+3 还是 2+debounce/throttle，都会引入 “异步”。爱因斯坦广义相对论大家都知道吧，一旦时间上解耦了，一致性就是虚构的。 至少，为什么不假装自己很愚蠢，用个正常的 form 来提交呢…… |
|
40
no1xsyzy 2020-03-10 15:26:04 +08:00
|
 |
41
fancy111 2020-03-10 15:30:39 +08:00
你们真的一顿瞎扯，确认密码只不过是为了让用户确认自己的输入是这样的，后端需要干嘛？以前根本没两个框。
再说了，不管是申请时还是修改密码时，提交之后不应该都要重新登录一次吗？ |
 |
42
whileFalse 2020-03-10 15:52:09 +08:00
@no1xsyzy #40 前端校验密码最简单的难道不是“确认修改”按钮被按下时么。
|
 |
43
weiqk 2020-03-10 15:59:18 +08:00 via Android
所有表单必须前后端同时验证，前端验证是为了用户能尽快发现并修正，后端验证是为了保证数据正确
|
 |
44
MisakaMikoto 2020-03-10 16:16:39 +08:00
就是脱裤子放屁
|
 |
45
CloudMx 2020-03-10 16:28:15 +08:00
没必要，前段三个框，一个旧密码，一个新密码，一个新密码重复(确认)，提交到后端，只需要，新密码，老密码，两个字段值，后端验证了老密码的正确性后再进行密码更改操作。
第三个密码框，在这里并没有增加安全性，但是增加了纠错，万一用户密码输入错误，还有余地。 |
|
46
CloudMx 2020-03-10 16:29:24 +08:00
中间人攻击会在意你后面的新密码有多少个密码字段？
|
 |
47
uminokoe 2020-03-10 16:29:45 +08:00 9
需要确认，万一前端忘记校验了，自己就不用背锅了
|
 |
49
zhjie 2020-03-10 16:42:51 +08:00
因为安全而说需要验证的，都在扯淡。
|
 |
50
loading 2020-03-10 16:49:20 +08:00
@whileFalse 是两次输入对不上时，确认修改按钮不可按。检测应该是 keyup，并且需要加上去抖。
|
 |
51
v2student 2020-03-10 17:04:51 +08:00
没有必要，你要验证的是原始密码，新密码如果是伪造的，伪造一个和伪造两个，又有什么区别？
|
 |
52
xixinimei 2020-03-10 17:57:51 +08:00
不需要，前端的锅前端背，干嘛拉着后端一起背？（手动狗头
|
 |
55
jim9606 2020-03-10 18:56:05 +08:00 1
不需要，现在的趋势是不要求重复密码（ PIN ）但提供查看星号的按钮
最佳实践是前端完成强度检查，只发送经过 KDF(Key Derivation Function)的密码（也就是 PIN 不离客户端），所有后端只使用 KDF 后的密码也就是后端也不知道 PIN 是啥。 不过我是没法奢望厂商采用最佳实践了，通常都是用 RSA 加密 PIN 后传服务器再解密。 有能力发布什么“弱密码统计”的几乎是没按照最佳实践做的 |
 |
56
Cbdy 2020-03-10 19:09:46 +08:00 via Android
多输一遍是防呆的，不用传到后
|
 |
57
ayase252 2020-03-10 19:19:01 +08:00
背锅论有点可笑....本身是纯前端的问题为什么要扔到后端。多一个环节就多一个出错的可能啊
|
 |
58
xuanbg 2020-03-10 21:16:09 +08:00
@jim9606 弱密码统计这个你可以用反向思维，就是枚举出若干种弱密码(基本上就是通用的密码攻击字典)，然后用这些弱密码按规则生成 KDF 后去碰撞，碰到的就是弱密码。不需要给密码还原为原始的 PIN。
|
|
59
xuanbg 2020-03-10 21:20:54 +08:00
|
 |
60
wleexi 2020-03-10 21:22:39 +08:00
后端是兜底操作。
|
 |
61
vkhsyj 2020-03-10 21:23:38 +08:00
没必要，但校验两次也没啥问题
|
 |
63
racecoder00 2020-03-10 22:58:50 +08:00
加个显示密码的按钮，取消确认密码框，完美
 |
 |
64
Torpedo 2020-03-10 23:18:48 +08:00
其实所有表单验证前后端都是要做的。
|
 |
65
charlie21 2020-03-11 00:35:06 +08:00 via iPhone
背锅论可笑？你背锅就开除你，开除是不是也很可笑？没饭碗是不是也很可笑？正好可以放假三个月 非常好
可以去西藏 |
 |
66
DeutschXP 2020-03-11 03:10:41 +08:00 1
这个问题其实很简单：
最早的时候是没有重复输入密码这个概念的，之后由于密码框是星号，很多人会输入错误，为了解决这个问题，也为了用户体验，引入了这个设计。 所以这个设计的作用，主要就是防止用户输入错误。 那么，如果现在要取消这个，无非几点： 1. 用户不会输入错误了，比如上面所说的，可以明文显示密码，而不再用星号遮盖 2. 无所谓用户是否输入一致，不行就重置密码 -- 这等于是个倒退的设计，所以不可取。 那么，如果还需要防止用户输入密码不一致，就必须要保证这个功能能够完成。这也牵涉到了另外一个问题：后端不要完全信赖前端传过来的任何数据，都需要重新验证。 现在的同学可能无法理解十几年前大厂的网页开发，严格意义上必须要保证浏览器在不支持脚本的情况下，也必须要能完成所有功能。 前端的任何 JS 校验，都只是为了用户体验，没有其他意义。上面很多人说，没重复验证的必要，可能是过于信赖前端了。就不说什么安全性了，很多人忽视了稳定性和兼容性。即使是自己的 App，都无法保证能够前端校验运行一直正常。而网页+JS，就更无法保证了： - 某个终端的某个浏览器版本，可能对你的前端 JS 校验代码并不完全兼容 - 某个 bug 可能会导致 JS 代码运行不正确 - 甚至是网页没有加载完全，某个插件出现异常，都可能会导致 JS 校验不工作 。。。。等等等等 你可能要说了，如果 JS 代码没有工作，好像也没什么安全问题啊，最多用户两次密码输入不一致，用户无法登陆呗，不是大问题。 那么，请重新阅读文字的最初，这个设计的目的是什么，就是为了给用户更好的交互体验，防止用户输入密码不一致。那么，前端不传数据，后端不校验，那么就可能有 0.01%的可能性无法实现这个目的。好像也没那么重要？但如果传递了，后端验证一下，并不麻烦，但可以把这个概率降低到了 0.0000001%，那么为什么不传递，非要弄一个不稳定的半成品出来呢？ |
 |
67
DOLLOR 2020-03-11 09:26:26 +08:00 1
|
 |
68
dcsite 2020-03-11 10:02:47 +08:00 1
我认为确认密码这个输入框本身应该去掉，没什么意义。
一般的网站本身设计了重置密码功能，无法登录时肯定重置密码。特别是现在 Chrome 自动生成密码功能，对于二次确认密码来说，多此一举。 综述：上古时期设计，用户体验不好，本身该功能就应去掉，后端也无须检测。 |
 |
70
IvanLi127 2020-03-11 12:12:28 +08:00 via Android
个人觉得没必要传，这不妨害系统安全。前端校验规则执行的时候翻车了，那也只是意味着帮助用户减少手滑打错密码的功能丧失了。不过都严重到校验规则跑出问题了，是不是要考虑用户还能不能跑得起来界面？
|
Select Language