修改密码表单中的"请再次确认新密码"字段需要一起传到后端吗

我觉得不需要，毕竟 js 发明的初衷就是在前端完成表单校验。

我认为不需要，传到后端再校验一次会增大服务器压力。但是要考虑出于种种原因，前端校验代码没有正确的执行时，如何善后。

中间者攻击了解一下?

不用的，只要做了非对称，上了 ssh 就差不多了，有些网站在输入密码时如果选择明文输入框打一次就够了

@nevin47 求解怎么个思路。。

更正 ssh->https

不会，确认密码这个只是防止他输错，并没有其他目的

就这个场景来讲：不需要。退一万步讲，即便前端校验代码没有正确执行，最坏的结果是用户密码更新成了非期望值。这种情况一是几率很小，二是可以被接受的。

其实现在有两个趋势：
1、不需要二次确认，只要输入一次即可； 2、用指纹代替密码。

还有个未来的趋势：
手误或者输入其他密码（如历史密码，其他网站通用密码），也可以顺利登陆。
这个有点抽象，解释一下：比如密码是 password，但是手指头抽筋输入了 pssswoed （对于移动设备，和可能的），后台在不保存明文密码的前提下，仍然可以识别并顺利登录。

目前来看，最好的这种方案是使用认证平台的统一登陆即可。。。

我认为需要，我的原则是不信任客户端。

二次确认的目的是防止输入错误，并不是为了安全，所以不需要

为了逻辑严谨，虽然前段已经经过了校验，但是对于后端不应该完全相信不过前段的。
所有逻辑都建议后端二次校验，因此我投需要的票

用户体验优化 感觉没必要去到后端再做一遍。


然后楼上解释原因，中间人攻击和逻辑严谨，
虽然这么说有些过分，但总的来说，还是有些像脱裤子放屁。

我的原则是完全不信任用户,
用户传上来的密码肯定不是他想要的，
我把他的密码替换成 123456 后再告诉他

后端不能完全信任前端

@nevin47 MITM 跟确认密码传输到后端有毛线关系.....

@183387594 #14 那为什么还要用户修改，重置不就好了

不需要，如果一个密码能被替换或修改，那么两个也是一样的，除非做其他校验，所以单纯讨论楼主的问题就是：不需要

@nevin47 解释一下思路，中间人攻击在楼主这场景中，传不传"请再次确认新密码"字段，有和差别？
最多就是前端验证如果有问题，密码被设置为了非期望值。
在我看来，没看到"请再次确认新密码"字段有传到后端的必要，这个和信任不信任前端输入没有关系。
真是 MITM 攻击的话，能改你密码字段，同样可以改你"请再次确认新密码"字段，改成一样的有额外的难度么？

我的原则是谁都不信，就不应该使用我的密码，难道这种公司的数据库不会泄露吗

@Steps #17

他已经狗头保命了哈哈哈哈

个人感觉。。。没必要“请再次确认新密码”

不需要传两遍。实际上很多网站注册或者找回密码都不需要再次确认了，密码输错的毕竟比较低，这样体验反而更好。

不需要传，后端只是保存密码后续登录时校验，再次确认只是为了用户确认密码是否是期望值。个人认为其实注册的时候让密码可见就可以省略再次输入了。

前端兴旺年代啊新产生的问题

古代的时候，整个 form 都会提交的，根本不需要问

不需要，那个只是为了防止用户误操作或者输入错误再次请求

@julyclyde 古代这个词笑到我了，哈哈哈哈

刚去看了一眼 Twitter 和 Facebook 的，都把确认密码放在参数里了，至于后端用不用就不知道了。

@delectate #9 生物识别是最不靠谱的了

技术角度来讲是不需要的，但是不怎么信任客户端，前端知道自己做了验证，但是作为后端没法确认前端是否做了验证，又或者是有输入性 bug ？另外，也不会给服务器什么压力，多几个字节？本来也没几个人会一直改密码，恶意攻击就是另一回事了，少几个字节人家也能攻击。

开发很多时候不只是跟技术做斗争，而是在和人做都在，很多防御性变成思路，有一部分是为了，出 bug 时，便于扯皮

需要考虑前端的代码是否能够正常运行，考虑极端情况比如用户可以在浏览器禁用 JS。如果前端代码在禁用 JS 的场景下通过提交表单把数据发到后端，这样就需要在后端做校验。

有用，万一攻击者只伪造了密码而忘记伪造确认密码，不就防下来了嘛

这个是一个好问题, 首先明确一点的是,所有前端输入的都是不友好的, 重复输入前端完全可以做校验 . 作为一个后端程序员,我会让前端传. 所有数据后端校验才是安全!

输两次只有一个目的：防止用户手误。前端校验一下两个 input 值相同就 OK 了。后端再校验一次的意义是啥? 咋还扯到 mitm 了

用 "不信任客户端" 或者 "中间人攻击" 做理由的，你就算输入两遍，人家中间人两个都改掉，那不还是没卵用？
数据安全是通信来保证的，输两遍不是为了安全，只是避免用户自己手误。

不用

设置重复密码的原因不是前端密码显示为*，然后怕用户输入密码错然后要重复输入一遍么，传到后端要用来干啥。

原想说不需要的，想了想似乎是需要的……
考虑前端（不仅仅 Web ）如何校验密码无非这几种：1、当框内内容发生改变时； 2、当键盘被按下时； 3、定时。
注意前两种事件在 Web 端非常不友好：1 有可能意外不触发，2 触发机会额外高，容易导致卡顿。注意，尤其各种输入法（ Windows 下御三家姑且有密码框关输入法，但操作系统太杂）。无论是 3 还是 1+3 还是 2+debounce/throttle，都会引入 “异步”。爱因斯坦广义相对论大家都知道吧，一旦时间上解耦了，一致性就是虚构的。
至少，为什么不假装自己很愚蠢，用个正常的 form 来提交呢……

@darkbluever NoScript 用过一段时间我都给忘了……
@kasper4649 我记得 twtr 和 fb 都可以关 JS 运行…… 大概是这个原因

你们真的一顿瞎扯，确认密码只不过是为了让用户确认自己的输入是这样的，后端需要干嘛？以前根本没两个框。
再说了，不管是申请时还是修改密码时，提交之后不应该都要重新登录一次吗？

@no1xsyzy #40 前端校验密码最简单的难道不是“确认修改”按钮被按下时么。

所有表单必须前后端同时验证，前端验证是为了用户能尽快发现并修正，后端验证是为了保证数据正确

就是脱裤子放屁

没必要，前段三个框，一个旧密码，一个新密码，一个新密码重复(确认)，提交到后端，只需要，新密码，老密码，两个字段值，后端验证了老密码的正确性后再进行密码更改操作。
第三个密码框，在这里并没有增加安全性，但是增加了纠错，万一用户密码输入错误，还有余地。

中间人攻击会在意你后面的新密码有多少个密码字段？

需要确认，万一前端忘记校验了，自己就不用背锅了

@uminokoe 还是老哥这个“背锅论”想得周到..

因为安全而说需要验证的，都在扯淡。

@whileFalse 是两次输入对不上时，确认修改按钮不可按。检测应该是 keyup，并且需要加上去抖。

没有必要，你要验证的是原始密码，新密码如果是伪造的，伪造一个和伪造两个，又有什么区别？

不需要，前端的锅前端背，干嘛拉着后端一起背？（手动狗头

@FallenTy 下联：后端完全不能信任前端！

@freakxx #13 脱裤子+1

不需要，现在的趋势是不要求重复密码（ PIN ）但提供查看星号的按钮
最佳实践是前端完成强度检查，只发送经过 KDF(Key Derivation Function)的密码（也就是 PIN 不离客户端），所有后端只使用 KDF 后的密码也就是后端也不知道 PIN 是啥。
不过我是没法奢望厂商采用最佳实践了，通常都是用 RSA 加密 PIN 后传服务器再解密。
有能力发布什么“弱密码统计”的几乎是没按照最佳实践做的

多输一遍是防呆的，不用传到后

背锅论有点可笑....本身是纯前端的问题为什么要扔到后端。多一个环节就多一个出错的可能啊

@jim9606 弱密码统计这个你可以用反向思维，就是枚举出若干种弱密码(基本上就是通用的密码攻击字典)，然后用这些弱密码按规则生成 KDF 后去碰撞，碰到的就是弱密码。不需要给密码还原为原始的 PIN。

@xuanbg
做一张弱密码表 t_key
select u.* from t_user u join t_key k on k.key = u.pw;
这个结果就是全部的弱密码用户。

后端是兜底操作。

没必要，但校验两次也没啥问题

@delectate
接受历史密码和其他网站通用密码是万万不可以顺利登陆的。。那是安全灾难。。

加个显示密码的按钮，取消确认密码框，完美

其实所有表单验证前后端都是要做的。

背锅论可笑？你背锅就开除你，开除是不是也很可笑？没饭碗是不是也很可笑？正好可以放假三个月 非常好

可以去西藏

这个问题其实很简单：
最早的时候是没有重复输入密码这个概念的，之后由于密码框是星号，很多人会输入错误，为了解决这个问题，也为了用户体验，引入了这个设计。
所以这个设计的作用，主要就是防止用户输入错误。
那么，如果现在要取消这个，无非几点：
1. 用户不会输入错误了，比如上面所说的，可以明文显示密码，而不再用星号遮盖
2. 无所谓用户是否输入一致，不行就重置密码 -- 这等于是个倒退的设计，所以不可取。

那么，如果还需要防止用户输入密码不一致，就必须要保证这个功能能够完成。这也牵涉到了另外一个问题：后端不要完全信赖前端传过来的任何数据，都需要重新验证。

现在的同学可能无法理解十几年前大厂的网页开发，严格意义上必须要保证浏览器在不支持脚本的情况下，也必须要能完成所有功能。
前端的任何 JS 校验，都只是为了用户体验，没有其他意义。上面很多人说，没重复验证的必要，可能是过于信赖前端了。就不说什么安全性了，很多人忽视了稳定性和兼容性。即使是自己的 App，都无法保证能够前端校验运行一直正常。而网页+JS，就更无法保证了：
- 某个终端的某个浏览器版本，可能对你的前端 JS 校验代码并不完全兼容
- 某个 bug 可能会导致 JS 代码运行不正确
- 甚至是网页没有加载完全，某个插件出现异常，都可能会导致 JS 校验不工作
。。。。等等等等

你可能要说了，如果 JS 代码没有工作，好像也没什么安全问题啊，最多用户两次密码输入不一致，用户无法登陆呗，不是大问题。

那么，请重新阅读文字的最初，这个设计的目的是什么，就是为了给用户更好的交互体验，防止用户输入密码不一致。那么，前端不传数据，后端不校验，那么就可能有 0.01%的可能性无法实现这个目的。好像也没那么重要？但如果传递了，后端验证一下，并不麻烦，但可以把这个概率降低到了 0.0000001%，那么为什么不传递，非要弄一个不稳定的半成品出来呢？

@loading
@no1xsyzy
这里不需要去抖。简单的字符串比较，每秒不到十次的触发频率，既不涉及 IO 也不涉及图形绘制，无论去不去抖，放以前最弱的 IE6 都没感知区别。
另外检测事件应该用 oninput 和 onchange，而 keyup 会丢失剪切、粘贴、拖拽的变动。

我认为确认密码这个输入框本身应该去掉，没什么意义。
一般的网站本身设计了重置密码功能，无法登录时肯定重置密码。特别是现在 Chrome 自动生成密码功能，对于二次确认密码来说，多此一举。

综述：上古时期设计，用户体验不好，本身该功能就应去掉，后端也无须检测。

@DOLLOR oninput 和 onchange 是都绑同一个函数吗？还是二选一也行？

个人觉得没必要传，这不妨害系统安全。前端校验规则执行的时候翻车了，那也只是意味着帮助用户减少手滑打错密码的功能丧失了。不过都严重到校验规则跑出问题了，是不是要考虑用户还能不能跑得起来界面？

@loading
选一个就行，这两个只是触发时机的区别。

@DOLLOR 不存在的，Electron 在 ibus 下会 input 和 change 事件。还有页面注入脚本的密码理器，不一定全都设计为主动触发事件，尤其还需要特地构造事件对象，然后再发送，这么复杂虽然密码管理器不太会有不一致的情况。
…… 不过主要还是 Progressive experience 吧。

@IvanLi127 是的，Progressive Enhancement （上面写错了……），你其实需要担心用户是否可以加载 Javascript。而且实际上 CSS 比 Javascript 快（得多）。