V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
392039757
V2EX  ›  程序员

我司前端把密码明文扔到 cookie 里面,这样做对吗

  •  
  •   392039757 · 2019-10-31 17:40:47 +08:00 · 20315 次点击
    这是一个创建于 1600 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我不是前端,不懂也不敢问 eg: Cookie: userPwd=123456; userName=ws201907

    187 条回复    2019-11-02 07:55:20 +08:00
    1  2  
    wenzichel
        1
    wenzichel  
       2019-10-31 17:41:57 +08:00
    赶紧开了吧,早晚得出事儿
    agdhole
        2
    agdhole  
       2019-10-31 17:44:06 +08:00
    早晚得出事儿
    usw
        3
    usw  
       2019-10-31 17:44:30 +08:00   ❤️ 1
    我们用 httponly,约束自己不要乱搞 cookie
    littleylv
        4
    littleylv  
       2019-10-31 17:44:40 +08:00   ❤️ 15
    你是真问还是假问的?
    如果真问,你也……
    wispx
        5
    wispx  
       2019-10-31 17:45:03 +08:00
    是个狼人
    turi
        6
    turi  
       2019-10-31 17:46:35 +08:00   ❤️ 1
    报公司名吧 ,以后绕着走
    lagoon
        7
    lagoon  
       2019-10-31 17:46:37 +08:00   ❤️ 4
    我已经淡定了。
    我还记得某次某个项目问后台,传输过程中账号密码不做个加密吗?答:为什么要加密?
    我还记得和同事争论了半天,加密到底有没有用。

    现在,我也开始反问,干嘛要加密?
    出事?出事的锅大概率不在你身上。
    用户?用户在意这些吗?
    领导?领导在意这些吗?

    逐渐混沌邪恶。
    392039757
        8
    392039757  
    OP
       2019-10-31 17:47:00 +08:00
    @littleylv 真的想问下,我也不管这块,没事就看了下我司的网站,发现没有公司这样搞的,就很好奇#_#
    392039757
        9
    392039757  
    OP
       2019-10-31 17:48:04 +08:00
    @lagoon 主要是领导也不知道,就算领导知道也不懂,还不是开发说了算 *-*
    392039757
        10
    392039757  
    OP
       2019-10-31 17:50:19 +08:00
    @usw 谢谢老哥,回头学习一下
    littleylv
        11
    littleylv  
       2019-10-31 17:51:19 +08:00   ❤️ 12
    @lagoon #7 传输过程中加密的意义不大。如果开了 https,更加没必要了
    mmixxia
        12
    mmixxia  
       2019-10-31 17:53:03 +08:00
    有比较大的安全隐患
    opengps
        13
    opengps  
       2019-10-31 17:54:30 +08:00
    挺好,将来绝对不用你背锅
    katsusan
        14
    katsusan  
       2019-10-31 17:55:20 +08:00
    那后台存数据库的时候呢,最好也看看。 好像说国家有条例规定不能明文存敏感信息
    yhxx
        15
    yhxx  
       2019-10-31 17:55:47 +08:00
    @lagoon 传输过程中貌似还真的是不需要加密
    sheeta
        16
    sheeta  
       2019-10-31 17:55:55 +08:00
    赶紧跑路
    lagoon
        17
    lagoon  
       2019-10-31 17:56:55 +08:00
    @littleylv 开了 https,不就已经加密了吗?
    littleylv
        18
    littleylv  
       2019-10-31 17:58:18 +08:00
    @lagoon #17 协议加密的我知道,我是说针对密码的字符串单独的加密
    lp7631010
        19
    lp7631010  
       2019-10-31 17:58:36 +08:00 via iPhone
    @lagoon 一般没什么人做传输过程中加密 或者直接上 https
    Kerwin1202
        20
    Kerwin1202  
       2019-10-31 17:59:29 +08:00
    没毛病
    lagoon
        21
    lagoon  
       2019-10-31 18:00:09 +08:00
    @lp7631010 http 不就是加密吗.....
    lagoon
        22
    lagoon  
       2019-10-31 18:00:35 +08:00
    @littleylv 这不是讨论的不加密的情况吗。。。。
    lagoon
        23
    lagoon  
       2019-10-31 18:00:53 +08:00
    @lp7631010 https 不就是加密吗....
    tinycold
        24
    tinycold  
       2019-10-31 18:02:17 +08:00 via Android   ❤️ 1
    @littleylv 没意义,你加密了密码,别人拿到加密后的密码根本不用解密,照着这个请求发过去你后端还是要认!
    littleylv
        25
    littleylv  
       2019-10-31 18:02:43 +08:00
    @lagoon #22
    你这不是杠吗。。。算了你赢
    lp7631010
        26
    lp7631010  
       2019-10-31 18:08:16 +08:00 via iPhone
    @lagoon 明显你说的不是指 https 好么 你要说包含了 https 那你赢了 你真棒
    exiaoxing
        27
    exiaoxing  
       2019-10-31 18:09:22 +08:00
    记得当年考驾照登录过一个网站,用户名和密码都在 url 里
    dmjob2015222
        28
    dmjob2015222  
       2019-10-31 18:11:50 +08:00
    你司肯定有大神坐镇
    luozic
        29
    luozic  
       2019-10-31 18:14:14 +08:00
    得出事儿
    mokeyjay
        30
    mokeyjay  
       2019-10-31 18:16:39 +08:00   ❤️ 1
    @lagoon #7 传输过程中对密码字符串本身加密确实没意义,前端的加密都是浮云
    lhx2008
        31
    lhx2008  
       2019-10-31 18:17:33 +08:00 via Android   ❤️ 1
    @lagoon 不需要加密,加密也没有办法保证安全
    rykka
        32
    rykka  
       2019-10-31 18:18:11 +08:00 via Android
    不知道为什么要存 cookie。
    用 session 不行?我觉得这个锅不是产品就是技术经理的
    cheeto
        33
    cheeto  
       2019-10-31 18:18:46 +08:00
    借楼问一下正确的前端加密方式~
    loveour
        34
    loveour  
       2019-10-31 18:19:01 +08:00
    必然不对。如果是我就怼,解决不了就离职。我觉得也不能只是工作,多少也得有点追求有点信念吧。有些事情可以忍,有些事情忍不了。
    userdhf
        35
    userdhf  
       2019-10-31 18:19:19 +08:00
    前端没有安全性可言。。
    rykka
        36
    rykka  
       2019-10-31 18:21:50 +08:00 via Android
    目测 lz 不是前端,不知道是做那一块的。
    如果不熟悉建议让技术负责人定。
    不要一上来就标题党
    YUyu101
        37
    YUyu101  
       2019-10-31 18:24:16 +08:00 via Android
    前端是用户的,用户泄密你拦不住,服务端是公司的,公司泄密才是你能管的。前端为什么存密码才是问题,难道除了登录还有什么服务需要密码吗?
    yuang
        38
    yuang  
       2019-10-31 18:24:27 +08:00 via Android   ❤️ 4
    我司也是,我说了没用,是说为了实现记住密码功能才这样做的。记住密码功能是这样做的吗
    alw
        39
    alw  
       2019-10-31 18:25:51 +08:00   ❤️ 2
    反正我做项目时,用户在前端输入密码时就加盐 hash 一次,传输到后端保存或验证密码时再加盐 hash 一次,不管怎么样,绝对不允许出现用户密码明文在任何环节保留。
    taogen
        40
    taogen  
       2019-10-31 18:26:30 +08:00 via iPhone
    前端为什么要操作 cookie,cookie 不是后端写入用来保持 http 请求的用户状态吗?前端传参数不是用 request body 吗?
    demonzoo
        41
    demonzoo  
       2019-10-31 18:27:52 +08:00
    @YUyu101 对啊,前端为啥要存密码?
    littleylv
        42
    littleylv  
       2019-10-31 18:30:53 +08:00   ❤️ 1
    @alw #39 那么我问你,“用户在前端输入密码时就加盐 hash 一次”,这个盐,你是不是写在 js 了,那别人不就知道了?所以跟没加密不是一样?
    后端加密的好处就是别人根本不知道你的盐
    nieyujiang
        43
    nieyujiang  
       2019-10-31 18:32:07 +08:00
    是个狼灭
    ffkjjj
        44
    ffkjjj  
       2019-10-31 18:35:16 +08:00
    @alw #39 后端保存的密码是可逆加密吗?
    mrdemonson
        45
    mrdemonson  
       2019-10-31 18:39:43 +08:00 via Android   ❤️ 7
    加密其实都是针对特定人加密的,
    https 是防网络中间人,
    数据库密码加密是放黑客、防运维、防开发,
    前段密码加密无实际意义,但也绝不能把密码放 cookie 里面
    crclz
        46
    crclz  
       2019-10-31 18:44:36 +08:00   ❤️ 2
    这个做法问题不大。cookie 中放<token>和放<明文密码>,大多数时候唯一的区别就是取消一个设备对账号的访问权必须修改密码,而采用 access-token 就只用废除 token 即可。其他的关于加密、窃取方面的行为都是没区别的。

    即使要甩锅,也是后端的锅:不应该提供 cookie 中明文密码认证的途径。管前端吊事。

    微软 asp .net core web 框架的做法是:cookie 附带一个 claim 和 security-token。claim 就是服务器签发的用户名的证明,好像是带签名( username+signature )的,密钥存在哪里我没有深究。security-token 每改一次密码或者重新绑定一次电话号码等都会变一下,这样就可以实现账号安全信息变更时自动废除之前的访问权,并且不用向用户呈现“token”或者设备的概念,只需修改密码或者电话号码就一切安全,比较符合自然的逻辑。
    tomczhen
        47
    tomczhen  
       2019-10-31 18:48:22 +08:00 via Android
    记住密码这个机制应该是浏览器控制的,用户可控。对 Web 应用而言记住登录状态不应该是记住用户口令与密码明文,而是一个凭证,也就是 token 或者别的什么。

    但是这个凭证确实不用加密。
    gamexg
        48
    gamexg  
       2019-10-31 18:54:46 +08:00 via Android
    @lagoon 开 https 传输中就没必要加密了。
    不开 http,加密也没大意义。
    aWangami
        49
    aWangami  
       2019-10-31 18:54:50 +08:00 via Android
    我猜锅是后端的,前端也只是被逼无奈
    superrichman
        50
    superrichman  
       2019-10-31 19:01:59 +08:00 via iPhone
    这是个严重的安全隐患
    Mohanson
        51
    Mohanson  
       2019-10-31 19:02:23 +08:00   ❤️ 12
    @lagoon

    复制一段以前我发过的话:


    最近正好接触密码学,简单和回答一下:在信道安全的假设下,对通信数据做加密是没有意义的。比如你登录远程 linux 服务器,你是直接输入明文密码的。而在信道不安全的情况下,对通信数据加密有意义又没有意义:因为你必须把密钥通过信道传送给对方。

    所以世界上正经的计算机科学家都在解决信道安全问题: https, ssl, tls 等,(删掉)而剩余的民科则在研究前端加密(删掉)

    原文见: https://www.v2ex.com/t/608692#r_8018696
    laoyur
        52
    laoyur  
       2019-10-31 19:04:53 +08:00   ❤️ 1
    @littleylv > 这个盐,你是不是写在 js 了,那别人不就知道了?
    注意他说的 hash 一词,别人能知道你的前端处理逻辑,也能拦截到 hash 后的值,但没法知道用户输入的原文啊
    hundan
        53
    hundan  
       2019-10-31 19:16:40 +08:00 via Android   ❤️ 1
    嗯 我想了想 既然是前端背锅 那么一定是输入密码的时候 js 记录 那么一定是没有 httponly 的 且不说日志里面是不是可能存了一大堆这种数据 一旦界面有 xss 之类的 就可以获取账号密码了 都不用做持久化

    这里对话上面的程序员们 有些人觉得 上个 https 防中间人就好了 你们知道有种东西叫做隐患 此外密码和 session 不同 密码是长期的 甚至可能多网站通用 以及可能包含用户信息
    lihongjie0209
        54
    lihongjie0209  
       2019-10-31 19:17:10 +08:00
    @laoyur #52 没必要用原文啊, 直接模拟请求发送 hash 之后的值给服务端, 服务端无法区分的
    index90
        55
    index90  
       2019-10-31 19:24:02 +08:00
    cookie 放敏感信息(密码,密文,token,key ),其实都没有问题,问题是明文。
    这里的明文是指用户所输入的字符串信息,原封不动地存储在 cookie 中,那么即有可能被泄露。

    正确的做法是,前端存储加盐哈希后的密码,这样文本存储在 cookie 中是没有问题的。这里就需要后端登录接口,所接受的密码字段,是哈希后的密码。所以这里后端可能也要背锅。
    index90
        56
    index90  
       2019-10-31 19:26:33 +08:00
    补充:
    LZ 所提的问题不是传输安全问题,不需要在中间人挟持或密码传输安全等问题上讨论。这些问题的答案我觉得#51 说得很好。
    这里的问题,应该是客户端信息安全问题。
    laoyur
        57
    laoyur  
       2019-10-31 19:35:15 +08:00
    @lihongjie0209 你没看懂 @alw 哥的意思,他这么做是为了 [保护用户密码明文] ,不是说为了防止传输过程中被截取(传的是 hash,截取了也泄露不了密码明文)
    index90
        58
    index90  
       2019-10-31 19:40:27 +08:00
    @laoyur hash 不等于加密,实在太多人分不清了,哎
    cyssxt
        59
    cyssxt  
       2019-10-31 19:40:28 +08:00 via iPhone
    前端加密意义是什么?代码都功能开的的,谈什么加密
    cp19890714
        60
    cp19890714  
       2019-10-31 19:41:11 +08:00
    @lagoon 加密肯定会更安全些, 但是既然加密了, 干嘛不直接用 HTTPS
    laoyur
        61
    laoyur  
       2019-10-31 19:43:07 +08:00
    @index90 > hash 不等于加密
    没错,你说的对。但是跟我说的有什么关系吗?
    我只是在阐述,alw 的做法,是为了让任何环节(键盘记录器、屏幕识别除外)都不泄露出用户的原始密码,我对这种做法表示赞同。
    cp19890714
        62
    cp19890714  
       2019-10-31 19:43:46 +08:00
    @lagoon 前端不仅要加密, 还要加盐,随机码,防止重放攻击, 麻烦的一比. 且大多是防君子不防小人.
    真正想安全, 还是得 HTTPS
    w99wen
        63
    w99wen  
       2019-10-31 19:45:31 +08:00   ❤️ 1
    不对。
    不敢怎么样,token 不是密码,token 可以失效,token 可以在用户异常 ip 变更的时候设置为失效。
    密码不能,只要是账号密码正确,哪怕一秒钟换 10 个 ip,也不能设置密码为失效。
    所以,暴露密码,绝对不对。
    laoyur
        64
    laoyur  
       2019-10-31 19:47:04 +08:00
    @index90 额,回复完才看到你 55 楼的回复
    原来是友军,我还以为你在怼我,非常抱歉……
    index90
        65
    index90  
       2019-10-31 19:50:02 +08:00
    @laoyur #61 只是表达附议,无意冒犯。

    @cp19890714 其实应该把前端理解成一个界面更加友好的“cURL”,接口安全,系统安全都应该是后端的责任。
    cuzfinal
        66
    cuzfinal  
       2019-10-31 19:54:37 +08:00 via Android
    明文放哪都不对
    wangxin13g
        67
    wangxin13g  
       2019-10-31 19:55:52 +08:00
    前端加盐 hash 意义是避免中间人攻击直接获取传输的明文账号和密码,但是无论前端是否加密 账号密码都不能放在 cookie 内的
    ksharp8
        68
    ksharp8  
       2019-10-31 19:59:55 +08:00
    一般要加密加盐加时间戳
    sunzongzheng
        69
    sunzongzheng  
       2019-10-31 20:00:34 +08:00 via Android
    密文防撞库
    hyy1995
        70
    hyy1995  
       2019-10-31 20:01:19 +08:00   ❤️ 1
    他该不会是想做“记住用户名和密码”这个功能吧。。。这也太骚了
    yxwzaxns
        71
    yxwzaxns  
       2019-10-31 20:04:27 +08:00
    前端加盐做个 hash 是对用户的尊重,表示我对你的密码内容没兴趣(此条只针对密码有意义或隐私的用户)
    hirasawayui
        72
    hirasawayui  
       2019-10-31 20:05:21 +08:00
    我司项目上了 https,但还是要求接口入参加密。。。。 请问这有必要吗?
    hushao
        73
    hushao  
       2019-10-31 20:18:37 +08:00 via iPhone
    密码在整个系统的流程中只有登陆和重置两种交互用的到...所以问题应该是为嘛要存在 cookie 而不是明文不明文...🤣
    xavierskip
        74
    xavierskip  
       2019-10-31 20:19:14 +08:00
    无论如何都不能明文存储用户密码。不管在那里。
    skylancer
        75
    skylancer  
       2019-10-31 20:26:02 +08:00
    存密码是傻子,无论是明文还是 hash 甚至加盐后的都不行
    为什么不选择 session, 验证有问题直接 revoke 就搞定了
    x66
        76
    x66  
       2019-10-31 20:26:02 +08:00
    @hirasawayui #72 没有必要,https 已经保证了信道安全。
    shansing
        77
    shansing  
       2019-10-31 20:26:21 +08:00
    @Mohanson 信道安全不安全不能一概而论,看是要防止窃听者还是中间人。诸如 DH 这类密钥交换算法,可以在不安全的信道中安全地交换密钥,不过不能防止中间人攻击。
    Varobjs
        78
    Varobjs  
       2019-10-31 20:43:34 +08:00 via Android   ❤️ 1
    这个还不是最骚的
    上个公司 (上市的) 他们活动页面,需要手机号验证码的,直接把验证码明文存 cookie,然后 js 比较 cookie 与用户输入是否一样来校验的。
    geekdocs
        79
    geekdocs  
       2019-10-31 20:45:26 +08:00
    我想知道什么样的需求要存密码呢?
    Varobjs
        80
    Varobjs  
       2019-10-31 20:45:56 +08:00 via Android
    另外 cookie 存密码做什么?方便 debug ?🐶
    Nicoco
        81
    Nicoco  
       2019-10-31 20:49:14 +08:00
    从入职到入狱……
    paulzhang1992
        82
    paulzhang1992  
       2019-10-31 20:56:03 +08:00
    也许只是个假的呢😂
    shuichengjian
        83
    shuichengjian  
       2019-10-31 21:11:02 +08:00
    前端路过。。。
    前端加密,一般混淆视听,没有多大意义。但实际操作还是会加密。

    这位老哥的问题在于: 把明文密码直接存 cookie。
    不管出于什么需求,都不能这么做。
    且个人意见: 完全看不到这样做的意义。
    phantomzz
        84
    phantomzz  
       2019-10-31 21:18:26 +08:00
    难道没人怀疑,既然前端直接存明文,后端是不是也用的明文?不然意义何在?
    lp10
        85
    lp10  
       2019-10-31 21:24:55 +08:00   ❤️ 3
    cookie 存明文密码跟桌面搞个 txt 存密码没有任何区别

    都需要被吊起来打
    areless
        86
    areless  
       2019-10-31 21:28:05 +08:00 via Android
    是哦,现在 https 了。像以前的 md5 之类的摘要传到后端对比或者创建 session id~~~api 用 key 去混进值里面尾部加所有字符串的 md5 摘要校验真没必要了呢。嘻嘻~~~
    likuku
        87
    likuku  
       2019-10-31 21:37:42 +08:00
    对不对?安全原则之一:
    加密所有的一切
    arayinfree
        88
    arayinfree  
       2019-10-31 21:42:39 +08:00
    对用户个人的隐私暴露增加风险, 如果亲戚同事朋友使用电脑看到 cookie 这些信息就把你密码暴露了.
    如果密码不是明文的话就还好.
    mcrwayfun
        89
    mcrwayfun  
       2019-10-31 21:43:33 +08:00 via iPhone
    12306 登录接口也是明文
    LokiSharp
        90
    LokiSharp  
       2019-10-31 22:06:07 +08:00
    其实没啥大问题,浏览器本身的密码储存的也是明文。
    ironMan1995
        91
    ironMan1995  
       2019-10-31 22:29:37 +08:00 via Android
    cookie 不是服务端发送的响应报文中的首部字段通知客户端保存的,之后每次请求都带上的么,所以你们用这个要解决什么问题?
    iMusic
        92
    iMusic  
       2019-10-31 23:14:47 +08:00
    跟他说:你好骚
    vmebeh
        93
    vmebeh  
       2019-10-31 23:17:59 +08:00 via iPhone
    后端把收到的参数都存到 log 里面去了,于是密码明文存在 log 中
    ljpCN
        94
    ljpCN  
       2019-10-31 23:34:28 +08:00 via Android
    登录的时候,是不是前端发送请求时,把密码用时间戳加密一下,后端用前端给的时间戳对称解密,这样是一种解决方案?一来没有明文,二来避免重放攻击,除非加密解密方法泄露了。
    newtype0092
        95
    newtype0092  
       2019-11-01 00:06:39 +08:00   ❤️ 1
    @Mohanson 前端在用户输入时对密码做哈希(不是加密!)这个不是密码学问题,而是社会工程学问题。。。
    不管什么途径,用户的明文密码流入服务器就是对用户隐私的不负责任。
    2643595423
        96
    2643595423  
       2019-11-01 00:26:26 +08:00 via Android
    就是数据库也不能明文储存啊
    wolfan
        97
    wolfan  
       2019-11-01 00:28:48 +08:00
    要不你委婉提醒下好打 MD5 一下也成不是。
    Kbyte
        98
    Kbyte  
       2019-11-01 02:01:28 +08:00
    @Varobjs 这种我也遇到过,甚至是大公司一个项目的主要登陆页面。直接从 cookie 里读取验证码明文,那费劲吧啦做个验证码不知道有啥意义,可能只能确保用户不走神儿吧
    BaiLinfeng
        99
    BaiLinfeng  
       2019-11-01 02:24:38 +08:00
    所以 cookie 和 token 有何区别
    msg7086
        100
    msg7086  
       2019-11-01 04:27:08 +08:00   ❤️ 3
    @alw @laoyur @index90

    > 任何环节(键盘记录器、屏幕识别除外)

    所以以前游戏盗号用得最多的键盘记录器就让你给除外了?

    > 绝对不允许出现用户密码明文在任何环节保留。

    最理想的情况是键盘内部加密,敲字符的时候直接通过某种算法进行转换,输入到文本框的直接就是密文,如果你不信任这台电脑的话,明文字符根本不能进到电脑里。

    如果你假定这台电脑是不安全不可信的,那么进了电脑以后再加密并不能解决安全问题。
    如果你假定这台电脑是安全可信的,那么只需要在离开电脑进入公共网络的时候加密( SSL )即可。
    在假定安全可信的环境里额外增加安全措施没有什么意义。



    除了一种情况。
    就是你不信任自己的服务器,怕自己服务器被人黑了会被人拿到用户的原始密码,所以决定不让原始密码进到自己的服务器里。
    这种情况我建议咨询网络安全团队……
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5907 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 06:11 · PVG 14:11 · LAX 23:11 · JFK 02:11
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.