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

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

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

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

    187 条回复    2019-11-02 07:55:20 +08:00
    1  2  
    Allianzcortex
        101
    Allianzcortex  
       2019-11-01 06:39:48 +08:00
    很多用户多个网站会用同一个密码,加盐 /加盐可以保证就算是这个密码在传输过程泄露了,用户的其他网站账户也相对安全。当然网站没有责任做这个
    Pastsong
        102
    Pastsong  
       2019-11-01 07:02:26 +08:00
    @msg7086 自己服务器本来就不该存原始密码,只存加盐的 hash
    Pastsong
        103
    Pastsong  
       2019-11-01 07:04:37 +08:00
    @Allianzcortex HTTPS 就是来保证密码在传输过程不会泄露的,明文没有问题
    Allianzcortex
        104
    Allianzcortex  
       2019-11-01 07:09:23 +08:00
    @Pastsong 嗯,就是前面说的信道问题,往好处想预防类似以前的 12306 这样的自签证书? belt & suspender
    Allianzcortex
        105
    Allianzcortex  
       2019-11-01 07:10:59 +08:00
    @Pastsong 服务器存密码明文的前车之鉴就是 CSDN
    laoyur
        106
    laoyur  
       2019-11-01 07:43:44 +08:00 via Android
    @msg7086 照你的理论,反正键盘记录器防不了,就啥安全措施都不用做了,别挣扎了,都明文好了,是这个意思吧?
    darknoll
        107
    darknoll  
       2019-11-01 08:17:46 +08:00
    用 httponly 还有 https,没什么卵事
    realpg
        108
    realpg  
       2019-11-01 08:22:31 +08:00
    @darknoll #107
    上别人电脑直接 F12 就看见明文密码了……
    alw
        109
    alw  
       2019-11-01 08:28:17 +08:00
    @msg7086 这是大佬
    我没想那么多,就是一把梭,hash 就完事了。
    sevenzhou1218
        110
    sevenzhou1218  
       2019-11-01 08:51:19 +08:00
    我司也是啊,至少我们组的是,还好做的是公司内部项目,单点都是明文传输。
    KuroNekoFan
        111
    KuroNekoFan  
       2019-11-01 08:57:00 +08:00 via iPhone
    不对
    OnlyShimmer
        112
    OnlyShimmer  
       2019-11-01 09:04:03 +08:00
    其实在 cookie 放账号密码没什么问题,我个人猜测一下应该是要做记住账号密码 (我做过...)我一般都是 Bash64 转换一下再把敏感字换换( userPwd,userName)之类,这种东西真的是防君子不防小人,能黑你的人那肯定是知道这些,只能防防那些只知道按 F12 的人啦,心理安慰大于实际应用,再说因为有这一功能(记住账号密码)其实在密码输入框改一下 type 就能看到明文密码(本人健忘,经常这样干),如果不是记住账号密码这一功能,就当我放了个屁......
    NerverLibis
        113
    NerverLibis  
       2019-11-01 09:06:53 +08:00 via iPhone
    @lagoon 中间人攻击
    NerverLibis
        114
    NerverLibis  
       2019-11-01 09:08:38 +08:00 via iPhone
    @mrdemonson 2028 位以上 dh 公钥才有点用,要不然几分钟就给破了
    msg7086
        115
    msg7086  
       2019-11-01 09:15:19 +08:00 via Android
    @laoyur 是的,我们这里连银行的网银都是这么操作的,密码明文直接送进 SSL 安全层。
    msg7086
        116
    msg7086  
       2019-11-01 09:18:20 +08:00 via Android
    @Pastsong 说的不是永久存储,是说内存变量。
    zdnyp
        117
    zdnyp  
       2019-11-01 09:19:24 +08:00
    https 也不是特别安全啊,看网络环境。没遇到过中间人攻击吗?如果是加密的,被截取到后端也认,那这个 cookie 也是有时限的,但是明文的,被截取到就任人宰割了。
    beastk
        118
    beastk  
       2019-11-01 09:24:25 +08:00 via iPhone
    前端还是有必要加密密码等数据的,你们怕是没被撞库过。还民科,怕是没吃过亏吧。
    annielong
        119
    annielong  
       2019-11-01 09:28:58 +08:00
    那百度的 BDUSS 不也是本地存,F12 复制出去就能用
    akakidz
        120
    akakidz  
       2019-11-01 09:35:41 +08:00
    后端不加密前端不都是多余的操作吗...顺便借楼问一下正确的前端加密方式~
    encro
        121
    encro  
       2019-11-01 09:41:02 +08:00
    1,cookie 会随着 http 请求头每次发送到服务器端,所以设置过多的 cookie 无形增加了传输带宽;
    2,cookie 可以被客户端修改,明文存储容易被黑客修改后进入其他账户,比如将用户名或角色修改为 admin,从而拥有管理身份;
    3,在传输过程中被拦截,因为各个地方接入服务商都是不干净的,现在 HTTP 网站被地方电信机房挂码概率为总体 20%以上,首次 80%以上,对方要拿密码是轻而易举的。
    liuzhiyong
        122
    liuzhiyong  
       2019-11-01 09:41:14 +08:00
    当然不对啦。
    xuanbg
        123
    xuanbg  
       2019-11-01 09:44:22 +08:00
    这种做法绝对是已经违法了。等保 2.0 了解一下
    killerv
        124
    killerv  
       2019-11-01 09:44:33 +08:00
    我见过一个事业单位的网站,有个记住密码功能,做法就是密码扔 cookie 里……
    skylancer
        125
    skylancer  
       2019-11-01 09:45:36 +08:00
    @zdnyp cert pinning 了解一下
    xiaokui
        126
    xiaokui  
       2019-11-01 09:45:36 +08:00
    这不扯么?赶紧修改吧
    akakidz
        127
    akakidz  
       2019-11-01 09:55:35 +08:00
    看了一下回复才明白楼主的意思,前端这样搞肯定是不行的:)
    qinxi
        128
    qinxi  
       2019-11-01 10:00:42 +08:00
    我见过 社交软件 用户列表返回值带明文密码的...

    好在这家公司倒闭了
    chennqqi
        129
    chennqqi  
       2019-11-01 10:05:10 +08:00
    首先不合规。
    其次不安全,楼上的这些兄弟不要混淆 https 和加密。https 解决的是传输信道的安全,不是解决密码验证逻辑的安全。
    还有楼上说的窃取 cookie 也可以获得登录权限的这种,窃取 cookie 和窃取密码是两种情况。你把密码存放到 cookie 里,别人拿了密码在哪儿登录都可以。你没有存放密码,别人窃取了 cookie,在 cookie 失效时就不能登录。另外如果服务端做了 cookie 客户端验证。也可以做到 cookie 其他地方登录无效的。
    chennqqi
        130
    chennqqi  
       2019-11-01 10:06:42 +08:00   ❤️ 1
    补充一下:说网站没有责任做这部分密码安全的请仔细读一下《网络安全法》,网络安全法实施后,这些是网站经营者的责任,由于网站经营者的责任导致用户损失的要承担法律责任
    laoyur
        131
    laoyur  
       2019-11-01 10:09:17 +08:00
    @killerv 你说的那个站,可能是 @13725151469wy 哥做的
    component
        132
    component  
       2019-11-01 10:10:34 +08:00
    安全感是自己给的,小伙子。
    keepeye
        133
    keepeye  
       2019-11-01 10:11:23 +08:00
    有的客户就是要求记住用户名+密码,下次不用手动输入,不是要记住登录状态,请问各位大牛前端该怎么实现才绝对安全?
    hakono
        134
    hakono  
       2019-11-01 10:22:26 +08:00 via iPhone
    @keepeye lastpass 解君愁
    Yvette
        135
    Yvette  
       2019-11-01 10:27:36 +08:00
    @keepeye 不是前端不了解,不过至少所有我用过的国内国外的网站,没有任何一个是可以选择记住密码的,都是只有记住用户名或者登陆状态
    pkoukk
        136
    pkoukk  
       2019-11-01 10:42:37 +08:00
    @msg7086
    很多用户的账号密码是多网站通用的,不做任何处理记录在 cookie 里,有着明显的隐私泄露问题
    上厕所的时候隔壁小哥看一眼你的电脑,就把你的账号密码抄走了,没问题么?
    确实对于前端来说,如果操作系统环境不受信任,任何加密都是无意义的。
    但是又不是所有安全问题都出在操作系统层面上
    nnnToTnnn
        137
    nnnToTnnn  
       2019-11-01 10:57:24 +08:00
    @Pastsong 举个攻击 HTTPS 的例子。

    A 客户端 用的 Google 浏览器 - 网址: xxx.com IP 1.1.1.1

    C 中间人 IP: 2.2.2.2

    攻击方案一

    ------ 1. 拦截用户的 dns 请求,将 xxx.com 请求跳转到 xxx.cn
    ------ 2. 将 xxx.com 降级为 http
    ------ 3. xxx.cn 用正常的证书进行签发,然后代理 xxx.com 的 http 请求
    ------ 4. 用户访问 xxx.com ,即可获取解密出来的所有数据

    攻击方案二

    ----- 1. 在 A 客户端中植入根证书
    ----- 2. xxx.com 解析到 2.2.2.2 ,反向代理到 xxx.com
    ----- 3. 用户访问 xxx.com ,即可获取解密出来的所有数据


    B 服务端 IP: 1.1.1.1 端口 443



    不知道你们为什么会觉得 https = 安全?
    keepeye
        138
    keepeye  
       2019-11-01 11:00:23 +08:00
    有的客户就是要求记住用户名+密码,下次不用手动输入,不是要记住登录状态,请问各位大牛前端该怎么实现才绝对安全?
    @Yvette
    @hakono
    我们做开发的呢,不要总是我以为,很多时候要面对客户以为,给钱的是大爷😭 当然如果有个靠谱的产品在前面怼客户那也行
    ihciah
        139
    ihciah  
       2019-11-01 11:01:02 +08:00 via iPhone   ❤️ 1
    贵司是出 ctf 题的吗
    fumichael
        140
    fumichael  
       2019-11-01 11:01:51 +08:00
    我觉得加盐加密更多是为了

    部分用户不同网站设置密码都是一样的 + A 网站密码泄露的情况下,避免了 BCDEFGH…其他网站被一锅端了

    同理,如果你把卡的密码都设置成一样,知道你一张卡的密码就知道了你其他卡的密码

    加盐加密就对用户的原始密码保护了,减少了碰库的可能

    以上都是我个人的想法,可能也有不对,仅供参考
    Mutoo
        141
    Mutoo  
       2019-11-01 11:12:33 +08:00
    抛开传输上的问题来讲。cookies 最大的问题是会被明文存到本地,例如 chrome 是存在未加密的 sqllite 里。
    (session cookies 除外)
    codehz
        142
    codehz  
       2019-11-01 11:20:51 +08:00
    @nnnToTnnn #137 你用方案一对着 google.com 试试,这就是为啥要有 HSTS 和 HSTS preload
    即使用方案二,EV 标记也会被删除)自签名证书无法显示 EV )
    w99wen
        143
    w99wen  
       2019-11-01 11:25:17 +08:00
    @fumichael
    你想的不对。
    sujin190
        144
    sujin190  
       2019-11-01 11:31:07 +08:00
    不是据说密码法生效后,网站泄露用户密码是违法的么
    楼上说网站没有责任为用户密码加密加盐,保证明文不会泄露窃取,你们是认真的么?谁说没责任了,作死也不能这么作吧
    zckevin
        145
    zckevin  
       2019-11-01 12:03:00 +08:00
    全站 HTTPS + HSTS
    用户禁止 third-party cookies
    可破
    msg7086
        146
    msg7086  
       2019-11-01 12:15:29 +08:00
    @pkoukk 你回错人了吧,我什么时候提到过 Cookie 了?
    fumichael
        147
    fumichael  
       2019-11-01 12:16:50 +08:00
    @w99wen #143 多多指教
    msg7086
        148
    msg7086  
       2019-11-01 12:22:58 +08:00
    @nnnToTnnn 对于能执行植入根证书到系统这样的 root 级操作的人,或者能把 HSTS 从系统中剥离的人,请你找出任意一种不需要修改键盘硬件而能保护用户密码的手段。

    如果你电脑的 root/最高管理员权限都被拿走了,你还跟我讨论 HTTPS 是否安全?建议先换一把门锁并重装系统,然后再看看这个神通广大的人有没有用伪基站和伪电信服务把你的整个互联网通信给中间人了。
    msg7086
        149
    msg7086  
       2019-11-01 12:30:41 +08:00
    @fumichael 不需要密码原文的地方永远不应该存储某一种能够还原成密码原文的数据。
    也就意味着网站的永久存储层里不应该用到任何「加密」算法,而应该用「散列」算法。

    至于每次鉴权时,明文密码在不可信环境(互联网)传输时,使用 SSL 里的非对称的向前保密算法做加密保证可信信道,使用可信渠道( CA 信任链)保证服务器端可信。这里是需要「加密」的。
    这种情况下只有两种泄密可能。一是你电脑环境不可信,比如有木马,或者像上面说的被人往系统 CA 里下了药。再一个是服务器内部不可信,比如服务器被人黑了,替换了组件,把密码提前拦截了。

    当明文密码安全到达服务器程序以后,程序就会加盐做散列(散列保证无法还原原文)。过了这一步以后,任何黑客都无法用这个来碰库了。
    hakono
        150
    hakono  
       2019-11-01 12:42:37 +08:00
    @msg7086
    @codehz
    路过说一下, 要绕过 HSTS 并不需要 root 权限,连任何账号都不需要。
    HSTS 本身是有漏洞的,在用户第一次访问网站的时候就被劫持了的话,HSTS 是没任何用处的

    至于为了填上 HSTS 这个坑出现的 hsts preload list,则是为了填上一个坑又引入的一个坑
    要把自己的域名加入 hsts preload list,整个周期走下来至少要十几周时间,差不多 4 个多月,这几个月时间足够让黑客拿到有用的信息了

    其次,hsts preload list 的坑还不止这点,为了安全和防止连 hsts preload list 自身都被网络劫持了,浏览器的做法是直接硬编码 hsts preload list 到浏览器里面,意味着你花了几个月时间让自己域名进了 hsts preload list,用户不更新浏览器依旧没用。
    试问,有哪个公司能保证上自己网站的用户永远使用最新版的浏览器。 最终,解决这个安全问题的方法就是将安全维护再一次交回了开发公司和用户手上。
    codehz
        151
    codehz  
       2019-11-01 12:47:27 +08:00
    @hakono #150 所以我加上了 HSTS Preload(其实你只要用咕咕噜出的新 gTLD,他们自动就会在 preload 列表里,比如.new .app
    为啥先说 HSTS 呢,因为没有 HSTS 就没有 Preload(
    msg7086
        152
    msg7086  
       2019-11-01 12:53:41 +08:00
    @hakono HTTPS 的安全措施是靠多方面努力的,是多方面合作产生的效果。
    一定要说的话,如果把用户的网线直接拔了,接进专有网络里,什么都给你劫持干净了,又不给 HSTS Preload,又不让用新版的浏览器,那当然什么都没有用了。

    另外,HSTS 对抗的是用户指明要求用 HTTP (即不输入 HTTPS://)的情况。在要求安全性的环境下,直接要求用户把完整的地址和协议输入进去,就不会产生这样的问题。

    换句话说,这不是 HTTPS 的错,这是用户没有使用 HTTPS 的错。在危险环境下使用 HTTP,和打网址打错域名其实是类似的结果,只不过前者多一步劫持而已。如果某网上银行的地址是 「 https://bank 」 ,那么你输入「 bank 」或者 「 http://bank 」 就和输入 http://xxyyzz 一样危险。(所以这要么是网站没说清楚的锅,要么是用户没敲对的锅了。)
    l4ever
        153
    l4ever  
       2019-11-01 13:47:15 +08:00
    你这算什么,我们公司的 api 直接 get 请求的用户名和密码, 牛的一皮. 还不是 http
    todd7zhang
        154
    todd7zhang  
       2019-11-01 13:48:26 +08:00
    前端加密的比喻就是

    在家里大门 敞开( http) 的情况下, 是否还有必要将小房间的门锁(前端加密)上。
    当然了小房间的门锁钥匙,有的就放在小房间门口(一眼就看到),有的放在茶几下面(混淆 js)

    所以,我觉得还是老老实实的关上大门吧 https
    miniwade514
        155
    miniwade514  
       2019-11-01 13:57:32 +08:00 via iPhone
    为什么要存密码呢?密码最安全的存储方式是用户的脑子🧠,要么就是以用户自己选择存到别的地方。写到 cookie 里面是无谓增加风险。
    no1xsyzy
        156
    no1xsyzy  
       2019-11-01 14:03:29 +08:00
    @cheeto 所有用户数据在客户端加解密,服务器不存储任何形式的密码(连加盐版本也不存储),参考 Mega、Lastpass、ProtonMail 等,但相应的有如下弊端:
    1、密码忘记不能找回账号内数据。你可以找回账号,但找回的只会是一个空账号,因为里面的数据只能靠之前的密码解密;唯一的解救手段是提供一个 Key 文件可以解密内容,但无法得到原密码,所以可以用 Key 文件找回之前的数据,但这一过程会清楚账号数据,所以拿到 Key 去拿别人账号必然被发现。
    2、不符合中华人民共和国反恐怖主义法的需要。
    hakono
        157
    hakono  
       2019-11-01 14:07:31 +08:00
    @msg7086
    你这就是抬杠了。我谈的是 HSTS 的问题,你跟我谈安全管理策略的问题。我们说的都不是同一件事,没看到我最后说的吗:
    “ 最终,解决这个安全问题的方法就是将安全维护再一次交回了开发公司和用户手上。” 这就是你谈的这些内容。

    顺便,你有点搞错论题了,我只是路过吐槽你这一句话
    “对于能执行植入根证书到系统这样的 root 级操作的人,或者能把 HSTS 从系统中剥离的人,请你找出任意一种不需要修改键盘硬件而能保护用户密码的手段。”

    要从 HSTS 方面下手,根本不需要把 HSTS 从系统中剥离,也根本不需要入侵到对方系统中,我吐槽的是这点
    no1xsyzy
        158
    no1xsyzy  
       2019-11-01 14:07:49 +08:00
    @mrdemonson 数据库加密并不能防运维和开发,Facebook 前车之鉴,会把明文密码打 log
    hakono
        159
    hakono  
       2019-11-01 14:09:57 +08:00
    @codehz 你估计只看到了我回复的一半内容……HSTS Preload 也有坑
    codehz
        160
    codehz  
       2019-11-01 14:15:42 +08:00
    @hakono #159 你也没看我括号的内容) gTLD 在 preload list 里的情况下,所有用这个 tld 的都能自动获得 hsts 加成,并不需要 4 个月的问题)
    no1xsyzy
        161
    no1xsyzy  
       2019-11-01 14:23:27 +08:00
    但是其实还要担心一点:现在大部分服务器是运行在 VPS 上的,实际上如果过程中以明文存储在内存上,如果 VPS 提供商扫描内存的话是可以知道密码的。试问在座有几个人会对自己服务器上传入的数据在 HTTP 层面先做随机化分布?(即 SSL/TLS 层解密后在内存位置是打乱的)
    Cookie 的另一个问题就是反授权时 token 之流方便一点,存用户名密码就需要重置密码了。
    no1xsyzy
        162
    no1xsyzy  
       2019-11-01 14:25:49 +08:00
    @l4ever get 不是 http ?没太明白
    l4ever
        163
    l4ever  
       2019-11-01 14:30:04 +08:00
    @no1xsyzy 按快了, 少了个 s 我就
    l4ever
        164
    l4ever  
       2019-11-01 14:30:26 +08:00
    @no1xsyzy 你看,又按快了, 少了个 s 我就 ctrl+enter 了.
    w99wen
        165
    w99wen  
       2019-11-01 14:48:16 +08:00   ❤️ 1
    @fumichael
    对于加密
    有两个基本概念:对称加密,非对称加密
    对于 hash 之类的,其实是取得摘要,指纹,或者说特征值,不是加解密。
    每个固定内容,特征值应该是唯一的。同时我们不能直接从特征值得到原内容,除非你计算过或者说记得这么一个对照表,有这些一一对应关系。
    但是这其中有一个问题,大部分需要取摘要的内容都很短,很容易被人们计算出来,并且保存到对照表中(这个表,就叫彩虹表),所以才要加盐,加上一段随机字符,将内容变长,比如扩充到 50 位,那这个 50 位的彩虹表,就已经无法建立了,太大了。
    加盐,是为了对抗彩虹表。这个是根本目的。
    w99wen
        166
    w99wen  
       2019-11-01 14:49:54 +08:00
    @fumichael

    加盐之后,攻击者不能从彩虹表获得 md5 之前的原内容。也就是我们的密码。
    aaronhua
        167
    aaronhua  
       2019-11-01 14:53:29 +08:00
    @chennqqi +1。有朋友做安全的,这种明文的是过不了等宝的。
    no1xsyzy
        168
    no1xsyzy  
       2019-11-01 14:54:30 +08:00
    @fumichael 数据库加盐加密主要是为了防止彩虹表和哈希字典的。
    人们早就知道 'E10ADC3949BA59ABBE56E057F20F883E' = md5('123456')
    但如果你采用加盐的方法,你看到 'hellomyzebra,yestheyaresocute:' '3A64C835017B142A97B5ADAECF249673' 又怎么知道密码是多少?
    没盐的情况下,你可以直接 select * from users where passhash = 'E10ADC3949BA59ABBE56E057F20F883E' 得到这些人密码是 '123456',甚至给一个哈希字典能够直接 select users.*, hashdict.hashee as password from users left join hashdict on users.passhash=hashdict.hashed 取出所有弱密码,整个耗时不过几秒。
    用上彩虹表的话 20 位以下密码也花不了多久。

    但加盐首先直接破坏彩虹表,其次弱密码爆破也需要很久,脱裤后有足够久的时间告警所有用户改密码了。

    数据库中更标准的是采用 bcrypt 等方式,单密码校验需要 1 秒(可调参使得时间更长),简单 6 位纯数字密码,数据空间达 100 万,就是十几天,还多半不会命中。
    no1xsyzy
        169
    no1xsyzy  
       2019-11-01 15:06:01 +08:00   ❤️ 1
    @w99wen 彩虹表不是对照表,而是一个依赖于特定的哈希函数 hash 和随意指定的、反转了定义域和目标域的函数(实质上是另一种 hash,不过通常生成的是变长字符串) rehash 构造的简化对照表,它的结构和 hash 强对应,

    彩虹表就算你在 6 位数字上加一位数字的盐,因为哈希算法被改变 new_hash = d=>hash(salt+d),导致整个彩虹表不可用,但对照表的话刚开始就构造 7 位对照表的话还是可以使用的。
    这就是为什么需要每个用户独立生成盐,否则还是可以用彩虹表。
    kiracyan
        170
    kiracyan  
       2019-11-01 15:24:12 +08:00
    明文保存密码都是弱智.不管在哪
    nnnToTnnn
        171
    nnnToTnnn  
       2019-11-01 15:25:09 +08:00
    @codehz
    @zckevin
    @msg7086

    方案一,可能说的不够详细但是 HSTS 是可以绕过的,包括现在的浏览器的硬编码

    攻击方案一

    ------ 1. 拦截用户的 dns 请求,将 google.com 请求跳转到 google.com.hook
    ------ 2. 将 google.com 降级为 http(正常请求获取到 google.com 的数据)
    ------ 3. google.com.hook 用正常的证书进行签发,然后代理 google.com (步骤二的数据)的 https 请求
    ------ 4. 用户访问 google.com.hook,即可获取解密出来的所有数据


    和原始访问的差距是

    之前访问的是 google.com

    拦截后访问的是 google.com.hook


    talk is cheap,show me the cod

    https://github.com/LeonardoNve/sslstrip2
    cydysm
        172
    cydysm  
       2019-11-01 15:31:40 +08:00 via iPhone
    反正不能明文就对了
    noobcoder1
        173
    noobcoder1  
       2019-11-01 15:59:24 +08:00
    你让他加个密不就完了 前面+个密 后面加个盐 这样就能防止 cmd5 那种网站搞撞库解密
    noobcoder1
        174
    noobcoder1  
       2019-11-01 16:09:28 +08:00
    @keepeye 这种做法上古时代了吧 现在都是前后分离 都是本地存 token 直接带过去鉴权的啊 没有直接重定向登陆的,如果登陆是有效的 直接跳到 next 后的地址就行了 不用手工点登陆了
    hakono
        175
    hakono  
       2019-11-01 16:14:59 +08:00
    @codehz 因为 .net .com 这些一般意义上的常用域名并不在内置的顶级域名里
    虽然谷歌内置了 40 多个顶级域名,但实际上这些域名基本都是很少用的域名

    可不是所有的网站都可以动不动换个域名的
    hspeed18
        176
    hspeed18  
       2019-11-01 16:19:52 +08:00
    不知道为什么那么多人觉得有问题。
    如果没有用 https,前端加密了也没什么卵用。
    如果用了 https,前端加密不是多此一举吗?
    ctblns
        177
    ctblns  
       2019-11-01 16:22:46 +08:00
    你不把账号密码加密存储到数据库,你丢到 cookie 像被日啊
    codehz
        178
    codehz  
       2019-11-01 16:25:41 +08:00
    @nnnToTnnn #171 你看看你给的链接,只是原始的 SSLStrip 加一点改进的版本,还是 4 年前 HSTS Preload 还没实施的时候的仓库。。。
    nnnToTnnn
        179
    nnnToTnnn  
       2019-11-01 16:39:48 +08:00
    @codehz 这是对抗 HSTS 的原理,因为 HSTS 是对于域名的。
    nnnToTnnn
        180
    nnnToTnnn  
       2019-11-01 16:41:20 +08:00
    @codehz HTTPS 否认这个是漏洞,当然 sslstrip2 也不是针对 https 而是绕过 https 的 hsts,并非真正的解决了 https 的 hsts
    nnnToTnnn
        181
    nnnToTnnn  
       2019-11-01 16:44:02 +08:00
    @codehz HSTS 依赖 dns 才能提供基础的域名服务。才能够正常访问网站 , 确实 https 是足够安全,可是目前而言 dns 并非足够安全,而 HSTS 依赖 dns 这就让中间人有了攻击 https 的可能性了
    xuanbg
        182
    xuanbg  
       2019-11-01 16:47:28 +08:00
    要实现记住密码没问题,密码应该存本地,不应该让密码离开本地通过网络来存储,哪怕加密的也不行。
    Composurext
        183
    Composurext  
       2019-11-01 17:06:35 +08:00
    借此问一下前端比好的加密方式是什么?就算加密后端拿到也要解密,是约定好的还是自己随便混淆一下
    cquan
        184
    cquan  
       2019-11-01 17:40:18 +08:00
    我记得最近出了一个密码法,到时候这种明文肯定是不允许的
    LeroyMooney
        185
    LeroyMooney  
       2019-11-01 17:57:13 +08:00
    @w99wen 学习了
    msg7086
        186
    msg7086  
       2019-11-01 23:37:37 +08:00 via Android
    @hakono 我本来就不是在反驳你。基于论题展开讨论,从各方面进行探讨和补充,怎么就成杠了。贵站这个动不动就说杠的风气是真的不好,搞的人完全不想正常讨论下去了。要么还是专注于互喷吧。不回了。
    IvanLi127
        187
    IvanLi127  
       2019-11-02 07:55:20 +08:00 via Android
    @lagoon #7 这段路,加不加密无伤大雅。存到数据库才需要加密
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1037 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 22:29 · PVG 06:29 · LAX 15:29 · JFK 18:29
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.