为安全问题,早上公司热烈讨论

2022 年 8 月 31 日
 wenzaiquan199
场景:用户在前端绑银行卡,实名认证,前端通过 https 请求,明文将数据传给后端,故测试给我提了个 bug 要我前端加密传输,我网上搜了搜,觉得前端目前拿不出什么方案加密比 https 安全

测试:你这个东西加个密传给后端
我:有 https ,有一定的安全保障了
测试:但是我接口请求能看到我的身份证号什么的
我:你能拦截到别人的请求么
测试:那肯定有人能拦截到
我:我随便加个加密可以,我们代码没做混淆,别人看代码直接知道什么加密方法,随便解了,别人能从 https 把这个解析出来,破解我们这个跟玩一样,加了有意义么
测试:我之前公司都做了啊

遂测试找前端 leader 说,然后后端 leader 就说前端传过来不用加,后端给前端加密的数据就行了,前端 leader 说要,然后他们吵了半天

末了前端 leader 跟我说,要有“安全意识”,我直接回你项目混淆都不做,我从加密库找个现成的加密方法,有用么

遂结束,我也不理 leader 了,来看看大家什么意见
17098 次点击
所在节点    问与答
188 条回复
Al0rid4l
2022 年 9 月 2 日
@m2276699 「非绝对安全就不做」我不知道你从哪里理解出这样的意思?这是你说的, 不是我说的.
为了安全, 一个好理由, 你可以什么都做, 也可以什么都不做, 也可以做一部分, 问题是, 这个职责的边界在哪里?
楼主的场景里, 为什么只要求对这个接口做加密? 为什么别的不做? 觉得内网日志会记录敏感信息, 为什么不让运维改? 觉得会有内鬼要不要再整个零信任环境? 觉得用户机器可能被装自签证书, 那要不要干脆界面上再弹个窗提示用户检查机器安全性? 这些都是能提高安全性的, 提一点是一点嘛, 反正没有绝对安全
安全是一个整体, 不是不让做, 是让这个测试用文档形式把理由说清楚, 为什么要做? 为什么只让前端做? 这不难吧, 不然只凭测试一句话口嗨, 好让自己 KPI++? 那这不是自欺欺人是什么? 那你测试今天能一句话提这个需求, 明天就能一句话提那个需求
cwaken
2022 年 9 月 2 日
你就 http 传输的数据加个盐,双方皆大欢喜
dingyaguang117
2022 年 9 月 3 日
@twl007 为什么我看到最高赞的回答恰恰是支持我的观点的 😂

This is an old question, but I felt the need to provide my opinion on this important matter. There is so much misinformation here

The OP never mentioned sending the password in clear over HTTP - only HTTPS, yet many seem to be responding to the question of sending a password over HTTP for some reason. That said:

I believe passwords should never be retained (let alone transmitted) in plain text. That means not kept on disk, or even in memory.

People responding here seem to think HTTPS is a silver bullet, which it is not. It certainly helps greatly however, and should be used in any authenticated session.

There is really no need to know what an original password is. All that is required is a reliable way to generate (and reliably re-generate) an authentication "key" based on the original text chosen by the user. In an ideal world this text should immediately generate a "key" by salting then irreversibly hashing it using an intentionally slow hash-algorithm (like bcrypt, to prevent Brute-force). Said salt should be unique to the user credential being generated. This "key" will be what your systems use as a password. This way if your systems ever get compromised in the future, these credentials will only ever be useful against your own organisation, and nowhere else where the user has been lazy and used the same password.
dingyaguang117
2022 年 9 月 3 日
@twl007 我并不是推崇微博的技术,我只是反对把 HTTPS 当银弹。

安全是个体系——这句话应该为啥感觉是我应该说的呢。HTTPS 是体系,RSA over HTTPS 是奇技淫巧?
twl007
2022 年 9 月 3 日
@dingyaguang117 因为你没看底下的评论罢了

RSA over HTTPS 的方案也不是随便拍个脑袋放一个静态公钥吧?你觉得大多数人随便拍脑袋实现一个就比 TLS 设计时候考虑得更加周全么?

何况如果 HTTPS 都被拦截了 多点时间分析你的加密逻辑返回一个修改过的公钥回去又能有多复杂……

反过来说如果不信任 HTTPS 应该给个理由吧 而不是单纯一句我不信任你还要再去加密一下 既然 HTTPS 都不信任 那我自己实现的逻辑就能够信任了么?
dingyaguang117
2022 年 9 月 3 日
@twl007 理由就是 plain text 传输只要攻击者做了 HTTPS 中间人就是无差别攻击,做了任何形式的二次加密就是为了抵抗无差别攻击。(当然最好的方式是用 bcrypt 这种计算量大的, 撞密码不友好 hash 算法,但是只限于密码这种无需解密原文的场景)

就算别人是针对你的网站做了逆向,也是增加了相当的难度。而且我觉得你是低估了逆向的难度,看个爬虫教程就能让破解了,是开发者能力不足。

如果觉得微博垃圾,也可以看看 Facebook 登录的加密。更不要说券商、银行等金融机构了。
dingyaguang117
2022 年 9 月 3 日
@twl007 另外并没有说过不信任 HTTPS ,是不能绝对信任。有更高的安全需求的场景,应该在应用层做额外的安全措施。

有些行业场景下,升级的安全举措是监管强制要求做的,你不做就是不符合安全标准,是不可以展业的。
twl007
2022 年 9 月 3 日
@dingyaguang117

国内这个环境 我能想到的唯一有点用处的就是在深信服之下 可能可以对抗一下他的 HTTPS 嗅探 但是一般用深信服也会强制安装公司的证书了 实际上你也很难真的去保证安全

至于说 HTTPS 无差别攻击 如果 HTTPS 真的那么容易被攻破的话 大家还是多担心一下自己的浏览内容为好 毕竟公司层面来说 你浏览的内容也不会比你的账户密码少到哪里去 而且如果密码加密的话 那你的任何表单的人和敏感信息都要加密但是我觉得楼主的 QA 只是集中关注了账户密码 对内容却视而不见

Facebook 的加密一样有人公开分析过了 文章在这里 https://hackmd.io/@Ostrym/facebook-client-side-encryption

只要你的代码要在前端展示出来 那么实际上对于信道攻击的防护只能说是有限保护 真要想完整保护还是需要靠着后端以及依赖与独立的 APP 而不是通过 web 的形式 最好结合 2FA 一起来保证安全 否则这些加密只是再是整个流程变得看起来更加安全

至于说行业场景下 另一个例子就是国内的银行很多都有自己的安全控件 每次登陆都要通过安全控件来做 但是你看一下国外的银行 很多知识间的网页登录而已 并没有要求你去装额外的插件来实现这些 你能说国外的银行这块的安全性做得比国内差么?这几年国内的隐私泄露难道都是因为前端没做密码加密引起的么?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/876693

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX