V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
LoremIpSum
V2EX  ›  信息安全

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

  •  
  •   LoremIpSum · 2020-03-10 10:41:53 +08:00 · 8349 次点击
    这是一个创建于 1703 天前的主题,其中的信息可能已经有所发展或是发生改变。

    个人感觉不需要,因为前端已经校验过了,后端再做一次 equlas 判断感觉没什么必要,但是看到有些开源项目也把这个字段传到后端做校验?请问把这个再次确认传到后端起到什么作用?

    73 条回复    2020-03-11 15:41:41 +08:00
    GaoGeYang
        1
    GaoGeYang  
       2020-03-10 10:44:06 +08:00
    我觉得不需要,毕竟 js 发明的初衷就是在前端完成表单校验。
    Explr
        2
    Explr  
       2020-03-10 10:45:18 +08:00
    我认为不需要,传到后端再校验一次会增大服务器压力。但是要考虑出于种种原因,前端校验代码没有正确的执行时,如何善后。
    nevin47
        3
    nevin47  
       2020-03-10 10:46:14 +08:00
    中间者攻击了解一下?
    murmur
        4
    murmur  
       2020-03-10 10:47:44 +08:00
    不用的,只要做了非对称,上了 ssh 就差不多了,有些网站在输入密码时如果选择明文输入框打一次就够了
    guolaopi
        5
    guolaopi  
       2020-03-10 10:47:44 +08:00
    @nevin47 求解怎么个思路。。
    murmur
        6
    murmur  
       2020-03-10 10:47:57 +08:00
    更正 ssh->https
    wunonglin
        7
    wunonglin  
       2020-03-10 10:50:00 +08:00   ❤️ 3
    不会,确认密码这个只是防止他输错,并没有其他目的
    monospace
        8
    monospace  
       2020-03-10 10:51:48 +08:00
    就这个场景来讲:不需要。退一万步讲,即便前端校验代码没有正确执行,最坏的结果是用户密码更新成了非期望值。这种情况一是几率很小,二是可以被接受的。
    delectate
        9
    delectate  
       2020-03-10 11:31:41 +08:00
    其实现在有两个趋势:
    1、不需要二次确认,只要输入一次即可; 2、用指纹代替密码。

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

    目前来看,最好的这种方案是使用认证平台的统一登陆即可。。。
    wanguorui123
        10
    wanguorui123  
       2020-03-10 13:23:17 +08:00
    我认为需要,我的原则是不信任客户端。
    hand515
        11
    hand515  
       2020-03-10 13:25:41 +08:00
    二次确认的目的是防止输入错误,并不是为了安全,所以不需要
    opengps
        12
    opengps  
       2020-03-10 13:44:17 +08:00
    为了逻辑严谨,虽然前段已经经过了校验,但是对于后端不应该完全相信不过前段的。
    所有逻辑都建议后端二次校验,因此我投需要的票
    freakxx
        13
    freakxx  
       2020-03-10 13:49:30 +08:00
    用户体验优化 感觉没必要去到后端再做一遍。


    然后楼上解释原因,中间人攻击和逻辑严谨,
    虽然这么说有些过分,但总的来说,还是有些像脱裤子放屁。
    183387594
        14
    183387594  
       2020-03-10 13:51:51 +08:00   ❤️ 1
    我的原则是完全不信任用户,
    用户传上来的密码肯定不是他想要的,
    我把他的密码替换成 123456 后再告诉他🐶
    FallenTy
        15
    FallenTy  
       2020-03-10 13:55:35 +08:00   ❤️ 1
    后端不能完全信任前端
    13k
        16
    13k  
       2020-03-10 13:58:03 +08:00   ❤️ 1
    @nevin47 MITM 跟确认密码传输到后端有毛线关系.....
    Steps
        17
    Steps  
       2020-03-10 13:59:00 +08:00
    @183387594 #14 那为什么还要用户修改,重置不就好了
    liuxey
        18
    liuxey  
       2020-03-10 13:59:24 +08:00
    不需要,如果一个密码能被替换或修改,那么两个也是一样的,除非做其他校验,所以单纯讨论楼主的问题就是:不需要
    Xusually
        19
    Xusually  
       2020-03-10 13:59:36 +08:00
    @nevin47 解释一下思路,中间人攻击在楼主这场景中,传不传"请再次确认新密码"字段,有和差别?
    最多就是前端验证如果有问题,密码被设置为了非期望值。
    在我看来,没看到"请再次确认新密码"字段有传到后端的必要,这个和信任不信任前端输入没有关系。
    真是 MITM 攻击的话,能改你密码字段,同样可以改你"请再次确认新密码"字段,改成一样的有额外的难度么?
    HongJay
        20
    HongJay  
       2020-03-10 14:00:11 +08:00
    我的原则是谁都不信,就不应该使用我的密码,难道这种公司的数据库不会泄露吗
    freakxx
        21
    freakxx  
       2020-03-10 14:04:25 +08:00
    @Steps #17

    他已经狗头保命了哈哈哈哈
    LokiSharp
        22
    LokiSharp  
       2020-03-10 14:08:50 +08:00
    个人感觉。。。没必要“请再次确认新密码”
    dndx
        23
    dndx  
       2020-03-10 14:09:09 +08:00
    不需要传两遍。实际上很多网站注册或者找回密码都不需要再次确认了,密码输错的毕竟比较低,这样体验反而更好。
    Airon
        24
    Airon  
       2020-03-10 14:15:52 +08:00
    不需要传,后端只是保存密码后续登录时校验,再次确认只是为了用户确认密码是否是期望值。个人认为其实注册的时候让密码可见就可以省略再次输入了。
    julyclyde
        25
    julyclyde  
       2020-03-10 14:16:01 +08:00
    前端兴旺年代啊新产生的问题

    古代的时候,整个 form 都会提交的,根本不需要问
    MeteorCat
        26
    MeteorCat  
       2020-03-10 14:17:00 +08:00 via Android
    不需要,那个只是为了防止用户误操作或者输入错误再次请求
    Hstar
        27
    Hstar  
       2020-03-10 14:32:45 +08:00
    @julyclyde 古代这个词笑到我了,哈哈哈哈
    kasper4649
        28
    kasper4649  
       2020-03-10 14:40:36 +08:00
    刚去看了一眼 Twitter 和 Facebook 的,都把确认密码放在参数里了,至于后端用不用就不知道了。
    efaun
        29
    efaun  
       2020-03-10 14:42:59 +08:00
    @delectate #9 生物识别是最不靠谱的了
    neilq
        30
    neilq  
       2020-03-10 14:56:50 +08:00
    技术角度来讲是不需要的,但是不怎么信任客户端,前端知道自己做了验证,但是作为后端没法确认前端是否做了验证,又或者是有输入性 bug ?另外,也不会给服务器什么压力,多几个字节?本来也没几个人会一直改密码,恶意攻击就是另一回事了,少几个字节人家也能攻击。
    neilq
        31
    neilq  
       2020-03-10 15:01:20 +08:00
    开发很多时候不只是跟技术做斗争,而是在和人做都在,很多防御性变成思路,有一部分是为了,出 bug 时,便于扯皮
    darkbluever
        32
    darkbluever  
       2020-03-10 15:04:27 +08:00   ❤️ 2
    需要考虑前端的代码是否能够正常运行,考虑极端情况比如用户可以在浏览器禁用 JS。如果前端代码在禁用 JS 的场景下通过提交表单把数据发到后端,这样就需要在后端做校验。
    KyonLi
        33
    KyonLi  
       2020-03-10 15:08:46 +08:00
    有用,万一攻击者只伪造了密码而忘记伪造确认密码,不就防下来了嘛
    jzmws
        34
    jzmws  
       2020-03-10 15:10:07 +08:00
    这个是一个好问题, 首先明确一点的是,所有前端输入的都是不友好的, 重复输入前端完全可以做校验 . 作为一个后端程序员,我会让前端传. 所有数据后端校验才是安全!
    whoami9894
        35
    whoami9894  
       2020-03-10 15:12:42 +08:00 via Android
    输两次只有一个目的:防止用户手误。前端校验一下两个 input 值相同就 OK 了。后端再校验一次的意义是啥? 咋还扯到 mitm 了
    icyalala
        36
    icyalala  
       2020-03-10 15:17:39 +08:00
    用 "不信任客户端" 或者 "中间人攻击" 做理由的,你就算输入两遍,人家中间人两个都改掉,那不还是没卵用?
    数据安全是通信来保证的,输两遍不是为了安全,只是避免用户自己手误。
    ryanlid
        37
    ryanlid  
       2020-03-10 15:19:39 +08:00
    不用
    HeiXiaoBai
        38
    HeiXiaoBai  
       2020-03-10 15:21:18 +08:00 via Android
    设置重复密码的原因不是前端密码显示为*,然后怕用户输入密码错然后要重复输入一遍么,传到后端要用来干啥。
    no1xsyzy
        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 来提交呢……
    no1xsyzy
        40
    no1xsyzy  
       2020-03-10 15:26:04 +08:00
    @darkbluever NoScript 用过一段时间我都给忘了……
    @kasper4649 我记得 twtr 和 fb 都可以关 JS 运行…… 大概是这个原因
    fancy111
        41
    fancy111  
       2020-03-10 15:30:39 +08:00
    你们真的一顿瞎扯,确认密码只不过是为了让用户确认自己的输入是这样的,后端需要干嘛?以前根本没两个框。
    再说了,不管是申请时还是修改密码时,提交之后不应该都要重新登录一次吗?
    whileFalse
        42
    whileFalse  
       2020-03-10 15:52:09 +08:00
    @no1xsyzy #40 前端校验密码最简单的难道不是“确认修改”按钮被按下时么。
    weiqk
        43
    weiqk  
       2020-03-10 15:59:18 +08:00 via Android
    所有表单必须前后端同时验证,前端验证是为了用户能尽快发现并修正,后端验证是为了保证数据正确
    MisakaMikoto
        44
    MisakaMikoto  
       2020-03-10 16:16:39 +08:00
    就是脱裤子放屁
    CloudMx
        45
    CloudMx  
       2020-03-10 16:28:15 +08:00
    没必要,前段三个框,一个旧密码,一个新密码,一个新密码重复(确认),提交到后端,只需要,新密码,老密码,两个字段值,后端验证了老密码的正确性后再进行密码更改操作。
    第三个密码框,在这里并没有增加安全性,但是增加了纠错,万一用户密码输入错误,还有余地。
    CloudMx
        46
    CloudMx  
       2020-03-10 16:29:24 +08:00
    中间人攻击会在意你后面的新密码有多少个密码字段?
    uminokoe
        47
    uminokoe  
       2020-03-10 16:29:45 +08:00   ❤️ 9
    需要确认,万一前端忘记校验了,自己就不用背锅了
    CloudMx
        48
    CloudMx  
       2020-03-10 16:32:00 +08:00
    @uminokoe 还是老哥这个“背锅论”想得周到..
    zhjie
        49
    zhjie  
       2020-03-10 16:42:51 +08:00
    因为安全而说需要验证的,都在扯淡。
    loading
        50
    loading  
       2020-03-10 16:49:20 +08:00
    @whileFalse 是两次输入对不上时,确认修改按钮不可按。检测应该是 keyup,并且需要加上去抖。
    v2student
        51
    v2student  
       2020-03-10 17:04:51 +08:00
    没有必要,你要验证的是原始密码,新密码如果是伪造的,伪造一个和伪造两个,又有什么区别?
    xixinimei
        52
    xixinimei  
       2020-03-10 17:57:51 +08:00
    不需要,前端的锅前端背,干嘛拉着后端一起背?(手动狗头
    oatw
        53
    oatw  
       2020-03-10 18:02:49 +08:00 via iPhone
    @FallenTy 下联:后端完全不能信任前端!
    wysnylc
        54
    wysnylc  
       2020-03-10 18:34:55 +08:00
    @freakxx #13 脱裤子+1
    jim9606
        55
    jim9606  
       2020-03-10 18:56:05 +08:00   ❤️ 1
    不需要,现在的趋势是不要求重复密码( PIN )但提供查看星号的按钮
    最佳实践是前端完成强度检查,只发送经过 KDF(Key Derivation Function)的密码(也就是 PIN 不离客户端),所有后端只使用 KDF 后的密码也就是后端也不知道 PIN 是啥。
    不过我是没法奢望厂商采用最佳实践了,通常都是用 RSA 加密 PIN 后传服务器再解密。
    有能力发布什么“弱密码统计”的几乎是没按照最佳实践做的
    Cbdy
        56
    Cbdy  
       2020-03-10 19:09:46 +08:00 via Android
    多输一遍是防呆的,不用传到后
    ayase252
        57
    ayase252  
       2020-03-10 19:19:01 +08:00
    背锅论有点可笑....本身是纯前端的问题为什么要扔到后端。多一个环节就多一个出错的可能啊
    xuanbg
        58
    xuanbg  
       2020-03-10 21:16:09 +08:00
    @jim9606 弱密码统计这个你可以用反向思维,就是枚举出若干种弱密码(基本上就是通用的密码攻击字典),然后用这些弱密码按规则生成 KDF 后去碰撞,碰到的就是弱密码。不需要给密码还原为原始的 PIN。
    xuanbg
        59
    xuanbg  
       2020-03-10 21:20:54 +08:00
    @xuanbg
    做一张弱密码表 t_key
    select u.* from t_user u join t_key k on k.key = u.pw;
    这个结果就是全部的弱密码用户。
    wleexi
        60
    wleexi  
       2020-03-10 21:22:39 +08:00
    后端是兜底操作。
    vkhsyj
        61
    vkhsyj  
       2020-03-10 21:23:38 +08:00
    没必要,但校验两次也没啥问题
    shiji
        62
    shiji  
       2020-03-10 21:26:42 +08:00
    @delectate
    接受历史密码和其他网站通用密码是万万不可以顺利登陆的。。那是安全灾难。。
    racecoder00
        63
    racecoder00  
       2020-03-10 22:58:50 +08:00
    加个显示密码的按钮,取消确认密码框,完美
    Torpedo
        64
    Torpedo  
       2020-03-10 23:18:48 +08:00
    其实所有表单验证前后端都是要做的。
    charlie21
        65
    charlie21  
       2020-03-11 00:35:06 +08:00 via iPhone
    背锅论可笑?你背锅就开除你,开除是不是也很可笑?没饭碗是不是也很可笑?正好可以放假三个月 非常好

    可以去西藏
    DeutschXP
        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%,那么为什么不传递,非要弄一个不稳定的半成品出来呢?
    DOLLOR
        67
    DOLLOR  
       2020-03-11 09:26:26 +08:00   ❤️ 1
    @loading
    @no1xsyzy
    这里不需要去抖。简单的字符串比较,每秒不到十次的触发频率,既不涉及 IO 也不涉及图形绘制,无论去不去抖,放以前最弱的 IE6 都没感知区别。
    另外检测事件应该用 oninput 和 onchange,而 keyup 会丢失剪切、粘贴、拖拽的变动。
    dcsite
        68
    dcsite  
       2020-03-11 10:02:47 +08:00   ❤️ 1
    我认为确认密码这个输入框本身应该去掉,没什么意义。
    一般的网站本身设计了重置密码功能,无法登录时肯定重置密码。特别是现在 Chrome 自动生成密码功能,对于二次确认密码来说,多此一举。

    综述:上古时期设计,用户体验不好,本身该功能就应去掉,后端也无须检测。
    loading
        69
    loading  
       2020-03-11 11:28:33 +08:00 via Android
    @DOLLOR oninput 和 onchange 是都绑同一个函数吗?还是二选一也行?
    IvanLi127
        70
    IvanLi127  
       2020-03-11 12:12:28 +08:00 via Android
    个人觉得没必要传,这不妨害系统安全。前端校验规则执行的时候翻车了,那也只是意味着帮助用户减少手滑打错密码的功能丧失了。不过都严重到校验规则跑出问题了,是不是要考虑用户还能不能跑得起来界面?
    DOLLOR
        71
    DOLLOR  
       2020-03-11 14:47:02 +08:00   ❤️ 1
    @loading
    选一个就行,这两个只是触发时机的区别。
    no1xsyzy
        72
    no1xsyzy  
       2020-03-11 15:31:35 +08:00
    @DOLLOR 不存在的,Electron 在 ibus 下会 input 和 change 事件。还有页面注入脚本的密码管理器,不一定全都设计为主动触发事件,尤其还需要特地构造事件对象,然后再发送,这么复杂——虽然密码管理器不太会有不一致的情况。
    …… 不过主要还是 Progressive experience 吧。
    no1xsyzy
        73
    no1xsyzy  
       2020-03-11 15:41:41 +08:00
    @IvanLi127 是的,Progressive Enhancement (上面写错了……),你其实需要担心用户是否可以加载 JavaScript。而且实际上 CSS 比 JavaScript 快(得多)。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3567 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 40ms · UTC 00:47 · PVG 08:47 · LAX 16:47 · JFK 19:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.