个人感觉不需要,因为前端已经校验过了,后端再做一次 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
个人觉得没必要传,这不妨害系统安全。前端校验规则执行的时候翻车了,那也只是意味着帮助用户减少手滑打错密码的功能丧失了。不过都严重到校验规则跑出问题了,是不是要考虑用户还能不能跑得起来界面?
|