这是一个创建于 813 天前的主题，其中的信息可能已经有所发展或是发生改变。
场景：用户在前端绑银行卡，实名认证，前端通过 https 请求，明文将数据传给后端，故测试给我提了个 bug 要我前端加密传输，我网上搜了搜，觉得前端目前拿不出什么方案加密比 https 安全
测试:你这个东西加个密传给后端
我:有 https ，有一定的安全保障了
测试:但是我接口请求能看到我的身份证号什么的
我:你能拦截到别人的请求么
测试:那肯定有人能拦截到
我:我随便加个加密可以，我们代码没做混淆，别人看代码直接知道什么加密方法，随便解了，别人能从 https 把这个解析出来，破解我们这个跟玩一样，加了有意义么
测试:我之前公司都做了啊
遂测试找前端 leader 说，然后后端 leader 就说前端传过来不用加，后端给前端加密的数据就行了，前端 leader 说要，然后他们吵了半天
末了前端 leader 跟我说，要有“安全意识”，我直接回你项目混淆都不做，我从加密库找个现成的加密方法，有用么
遂结束，我也不理 leader 了，来看看大家什么意见
测试:你这个东西加个密传给后端
我:有 https ，有一定的安全保障了
测试:但是我接口请求能看到我的身份证号什么的
我:你能拦截到别人的请求么
测试:那肯定有人能拦截到
我:我随便加个加密可以，我们代码没做混淆，别人看代码直接知道什么加密方法，随便解了，别人能从 https 把这个解析出来，破解我们这个跟玩一样，加了有意义么
测试:我之前公司都做了啊
遂测试找前端 leader 说，然后后端 leader 就说前端传过来不用加，后端给前端加密的数据就行了，前端 leader 说要，然后他们吵了半天
末了前端 leader 跟我说，要有“安全意识”，我直接回你项目混淆都不做，我从加密库找个现成的加密方法，有用么
遂结束，我也不理 leader 了，来看看大家什么意见
第 1 条附言 · 2022-08-31 16:17:25 +08:00
可能大家误解我的意思了，我不是说前端加密没用
首先这事是我做一个功能时，然后测试给我提的 bug ，她的意思我懂，就是不想要明文传给后端，那我觉得我不懂这一块，总不能上网真搜个什么常用加解密就跟后端搞了吧，所以我就拒绝了，安全的事情让她去找前后端领导让他们决定或者出方案排期，然后前后端领导就吵起来了，后端领导觉得不用，前端领导觉得要用，前端说不过后端，然后跑来找我们撒气，说我们前端开发没有安全意义，给我整毛了，我也没见他平时对我们项目做什么安全方面的要求处理，现在吵不过别人就来找我们撒气，回了他一嘴
当然我知道加密比不加密有用，但是如果我加密的效果真是 base64 那种方案，那有什么意义呢
首先这事是我做一个功能时，然后测试给我提的 bug ，她的意思我懂，就是不想要明文传给后端，那我觉得我不懂这一块，总不能上网真搜个什么常用加解密就跟后端搞了吧，所以我就拒绝了，安全的事情让她去找前后端领导让他们决定或者出方案排期，然后前后端领导就吵起来了，后端领导觉得不用，前端领导觉得要用，前端说不过后端，然后跑来找我们撒气，说我们前端开发没有安全意义，给我整毛了，我也没见他平时对我们项目做什么安全方面的要求处理，现在吵不过别人就来找我们撒气，回了他一嘴
当然我知道加密比不加密有用，但是如果我加密的效果真是 base64 那种方案，那有什么意义呢
第 2 条附言 · 2022-09-01 12:06:15 +08:00
我不知道是我没表述清楚还是什么，我没说测试发现这个问题有问题，安全这是一个大问题，但是这是一个 bug ，难道我要来个 base64 糊弄一下么，这是需要完整方案的东西和规范的，要不要加密？怎么加密？加密到什么程度？
所以我跟她的态度就是这个不是 bug ，是个大东西，这次我修复不了，她不肯，一定要我这次加，我说你一定要我加，去找前后端 leader 给我方案，安全相关的东西我负责不了，经验不够
然后前后端 leader 开始吵了，后端 leader 的观点是，前端不需要，https 保证了大部分安全的场景，后端方面加密数据给前端就行了，而且我们一没规范，二人员少（开发团队前端+测试+后端+2leader 总共 7 个人），要搞这方面的东西话投入太多，取舍的话就是没必要
前端 leader 也在那吵，说要，一定要，但是拉着后端老大吵了半小时什么技术方案不给，说来说去就是 https 就不安全么巴拉巴拉，我能怎么怎么破解，最后后端老大不想理前端老大，然后前端老大跑到我们前端面前说我们前端没安全意识，我就烦了，他自己一直没出什么安全方案规范，甚至公司的项目混淆没混淆都不知道，最后丢到我们干活的头上，我就回了
所以我跟她的态度就是这个不是 bug ，是个大东西，这次我修复不了，她不肯，一定要我这次加，我说你一定要我加，去找前后端 leader 给我方案，安全相关的东西我负责不了，经验不够
然后前后端 leader 开始吵了，后端 leader 的观点是，前端不需要，https 保证了大部分安全的场景，后端方面加密数据给前端就行了，而且我们一没规范，二人员少（开发团队前端+测试+后端+2leader 总共 7 个人），要搞这方面的东西话投入太多，取舍的话就是没必要
前端 leader 也在那吵，说要，一定要，但是拉着后端老大吵了半小时什么技术方案不给，说来说去就是 https 就不安全么巴拉巴拉，我能怎么怎么破解，最后后端老大不想理前端老大，然后前端老大跑到我们前端面前说我们前端没安全意识，我就烦了，他自己一直没出什么安全方案规范，甚至公司的项目混淆没混淆都不知道，最后丢到我们干活的头上，我就回了
 |
101
adoal 2022-08-31 22:17:16 +08:00
什么时候轮到测试来提功能需求了？
|
 |
102
dddd1919 2022-08-31 22:20:37 +08:00
@xsen 敏感信息明文存储当然有问题，但敏感信息明文在 https 消息体中传输，有什么问题？
测试如果说自己能拦截 https 请求体并查看明文内容，op 又因为这自觉理亏，那只能说 op 和测试水平半斤八两，基本原理都搞不懂的俩人吵吵没任何意义，老老实实加 base64 糊弄吧 |
 |
103
Bingchunmoli 2022-08-31 23:19:37 +08:00 via Android
依赖 https 的肯定会出问题的一天，目前国内普通用户对于中间人等手段无感，提示不安全还是点击继续访问的，不如 rsa 二次加密（真的有安全需求或者等保）
|
 |
104
3dwelcome 2022-08-31 23:23:16 +08:00
我前端不仅加密，而且数据流都是二进制格式，普通人根本没办法拦截。因为我用 wasm （自豪，骄傲）
|
 |
105
zhaogaz 2022-08-31 23:32:25 +08:00  3
你说的没问题，如果这个事儿是我，我会这么搞
1. 同意测试说的内容。 2. 按照优先级和方案排这个需求。 3. 同步给领导 接下来大概率的事情是，如果有人跟这个事儿，这个可能会开发，如果不重要那么就一直挂着。 你说的前端没混淆是对的，那应该有人追前端来改，而不是你暂时不做的理由。 事实上你工作的很多事情，也不都有意义，你争这个意义有什么作用呢？ |
 |
106
mogazheng 2022-08-31 23:42:23 +08:00
这几天测试阶段也遇到类似的问题，虽然不是安全问题，但道理是相通的。
任何人提出的任何需求，不管多奇葩，在某些特定场景肯定是能起到某些的作用。 你说再你研究研究那些最新论文，找个连量子计算机都爆破不了的密码算法，给网站的明文加密，有用吗，也肯定有的，至少可以防多几个顶尖密码专家的破解，防止未来量子计算机的破解。但是有必要吗，那就得看项目的实际场景了。 所以说，抛开场景提需求，那都是不切实际的。 |
 |
107
dingyaguang117 2022-08-31 23:51:46 +08:00
`我网上搜了搜，觉得前端目前拿不出什么方案加密比 https 安全`
-- 没搜到非对称加密方案？ |
 |
108
mikewang 2022-09-01 00:53:42 +08:00
测试：公司有自签名根证书，确实能拦截到别人的 https 请求啊
|
 |
109
Chihaya0824 2022-09-01 01:01:24 +08:00
@dingyaguang117 那怎么解决公钥交换的问题？ 对了，要不我们搞一套解决方案，就叫 TLS 好了（ doge
|
 |
110
aheadlead 2022-09-01 01:03:53 +08:00
很多公司的电脑上都是有装额外的根证书的，总不能说这种用户就一定不是你们的目标用户吧。
|
|
111
aheadlead 2022-09-01 01:05:36 +08:00
虽然说装了额外的根证书，基本上没啥可以防得住，但还是可以提高攻击者的成本的。多数的攻击者碰到前段混淆加密的情况，会选择去寻找更低成本更有价值的目标。
|
 |
112
GeruzoniAnsasu 2022-09-01 04:34:23 +08:00
一个鉴权被两拨不懂安全的人吵成了传输层加密安不安全的话题
|
 |
113
daveh 2022-09-01 07:48:23 +08:00 via iPhone
@Chihaya0824 #109 都公钥了，http 明文传给前端都没事。
如果产品是自己使用，前端写死公钥，后端保护好私钥；如果产品卖给别的客户使用，用接口传递对应公钥给前端，后端私钥能随时更换。 感觉 OP 是没找到合适加密方法才来抱怨的，前面有的人答的没错，非对称加密是正解，一个简单的 RSA 就搞定，可以解决 OP 的问题。 |
|
114
daveh 2022-09-01 08:18:41 +08:00
另外，如果实在是不想加密，有 app 的话开一下 SSL pinning ；只有浏览器访问的话开一下网站开一下 HSTS 。
但这些都防不了作死用户越狱系统、使用不安全浏览器。 |
 |
115
cssk 2022-09-01 08:41:12 +08:00 via iPhone
要么…要么…
|
 |
116
wonderfulcxm 2022-09-01 08:48:19 +08:00 via iPhone
纯属脱裤子放屁，如果 https 传输都能被拦截了，加不加密有什么区别？
|
 |
117
zhw2590582 2022-09-01 08:52:05 +08:00
base64 解君愁啊，反正弄到测试看不懂就行，一次不够就两次 base64 ，只是打工，不要较真，谁怕谁啊
|
 |
118
66beta 2022-09-01 09:00:33 +08:00
年轻的我： https 都被截了，你说个*8
现在的我：上国密！ |
 |
121
laolaowang 2022-09-01 09:15:35 +08:00
理解楼主， 测试可以提出意见、或者建议，但是这东西不能当做 bug （功能）直接提给前端，
如果之前需求提了要加密，那就是前端的锅，如果没有提，测试干脆去写需求把 这东西应该向上报告，排期啊 |
 |
122
penll 2022-09-01 09:17:36 +08:00
没人问是 Web 得前端吗？如果 web 前端，那加密真没啥用。破解成本太低了。就算混淆之后
|
 |
123
CodeCodeStudy 2022-09-01 09:18:53 +08:00
这个测试半吊子，他肯定不懂技术，弄个 base64 就得了。
但是这个算不算 bug ，要看产品给的需求文档或原型里有没有这个要求，如果没有则不能算 bug |
 |
124
hideonwhere 2022-09-01 09:24:59 +08:00
我那测试还能边测边提需求
|
 |
125
TGl2aWQgZGUgZGll 2022-09-01 09:31:24 +08:00
至少可以增加一些人要动你们数据的门槛，这就够了。
不一定是要破解 https ，比如某个用户，就想抓包改数据啥的，来利用某些活动之类的功能，达到快速刷积分的目的啥的，如果数据有一定的加密编码啥的，至少他看不到明文数据，可以把一些不是很懂前端算法的人吓退了。 再说了，你们领导说加，那就加，你就负责干就行了。 那些说没必要的人，那 js 算法各种混淆按道理也都没必要，因为反正有能力的人一样能看懂。关键是增加了很多破解成本啊 |
 |
127
ren2881971 2022-09-01 09:42:08 +08:00
给客户端和服务端都发放 CA 证书，采用双向 SSL 认证。
客户端和服务端都能够认证身份。 信息传输过程中都会使用对方的公钥进行消息加密，被拦截也解密不了。 |
 |
128
sampeng 2022-09-01 09:45:12 +08:00
前端坐 rsa 是可行的。n 年前微博没 https 就是自己搞了一套 rsa 加密。而且代码也没混淆。研究了一下，非常巧妙。
但是开发成本确实不小，要衡量收益。 发展到现在手段就很多了： 1.自己写交换公钥逻辑，其实不需要把公钥保存在客户端里面，每次请求的时候先找服务器要一下公钥。微博当年的方案就是这样搞的，而且每次的公钥都不相同，因为私钥直接就可以生成公钥。 2.wsam 。现代浏览器都支持。 3.控件，插件等等。 还是看安全和收益的比例。。 当然，这是技术讨论。其实 OP 反感的是测试提这样的 bug 。。。怎么看都应该是产品提，产品来判断要不要搞，产品来协调资源和排期。 |
 |
129
jianghu52 2022-09-01 09:47:08 +08:00
5 年前的我，估计会顶着压力，不加密。
3 年前的我，估计会跟 leader 吵吵一顿，然后加上密 现在的我，会心理鄙视一番，然后默默的找一个最通用的加密方式 |
 |
130
astkaasa 2022-09-01 09:54:52 +08:00
前端怎么加密?
|
 |
131
Huelse 2022-09-01 09:55:11 +08:00
老老实实给他们上加密呗，你永远不知道用户环境是怎样的，证书问题、控制台监听等等都有可能造成泄漏，反正加就完事了
|
 |
132
Stevenv 2022-09-01 09:58:42 +08:00
然后你成功让网友们也吵起来了 哈哈
|
 |
133
wzy44944 2022-09-01 10:07:33 +08:00
问题的核心不是前后端老大不对付吗？为啥一群人讨论安全
|
 |
136
goodname 2022-09-01 10:55:25 +08:00
终于碰到专业对口得了，作为信息安全人士说两句。
1.https 默认视为没有中间人攻击，客户自己瞎信任证书，导致信息泄露管不了 2.https 的 request body 通常不需要混淆（金融对安全要求高，但也没必要），一些重要接口会做下摘要防篡改，也是防菜鸟不防高手 3.response 如果有敏感信息，是需要打码传给前端的 |
|
137
goodname 2022-09-01 11:12:49 +08:00
@goodname 补充下业内前端与安全相关的一些事情
1.js 混淆（必做） 2.防篡改（选做） md5 摘要 3.人机验证（选做）点选验证，滑动验证 4.加密传输（ http 必做，https 选做）传输账户密码，个人信息时用 |
 |
138
fbi007130 2022-09-01 11:14:44 +08:00
都是成本与效益问题。
|
 |
139
twl007 2022-09-01 11:25:52 +08:00 via iPhone
|
 |
140
amon 2022-09-01 11:28:38 +08:00
现在讨论个技术问题也乌烟瘴气的吗？还是很高兴有不少人和专业对口的出来提出自己的意见。
作为一个非安全相关但经历多个大中小项目的老菜鸡出来叫嚷两句： 1. 大一点的公司会有敏感数据安全等级，身份证 /银行卡号这些应该是比较高的安全级别，差不多仅次于各种密码 2. 对于不同安全等级的数据会有不同的数据处理要求和规范。如果公司已经有明确的规范，请遵守；否则如果公司有信息安全人员，请咨询；否则请咨询 Leader 3. 接第 2 条，有些敏感数据处理规范不单是企业的要求，也是行业的标准。比如金融行业，数据合规是一个重要的工作，其中就包含数据存在哪怎么存怎么加密怎么展示等等 4. HTTPS 并非绝对安全，如果明文传输将会有很多种方式泄露数据（这个我不专业，请参考其它专业对口的人的发言） 5. 测试是个好同志，会根据之前公司的经历主动提出优化改进的地方，请对事不对人吧 |
 |
141
libook 2022-09-01 11:29:31 +08:00
我们公司在北京，这边安全方面查得很严，监管部门会直接要求任何个人敏感信息都要求必须二次加密，确保真正需要解密的地方才解密（也就是说你的负载均衡、反向代理、网关之类的也不应该进行解密），具体哪些算个人敏感信息可以参考国家标准 GB/T 35273-2020 的附录 B 。
二次加密这个用个非对称加密方案就可以了，前端放个公钥，后端用私钥解密，公钥随便公开，只要确保加密后的密文不被轻易抓包解密就可以了。 你们的问题归根结底其实是职责划分不清，导致前后端在这个灰色地带丧失决策能力。现在凡是一定规模的企业都至少需要个专职的安全团队来负责提供安全方案，你们现在没有的话，估计将来监管落到你们所在的地区也会要求你们有一个，很多合规工作靠前后端技术人员兼任是做不过来的，而且专门的安全团队必须给你们做安全培训和考核（监管部门会查培训和考核记录的），帮你们树立起安全意识。 |
 |
142
blackshow 2022-09-01 11:33:46 +08:00
让他抓个包看一下就行了，https 本来就是通道加密
|
 |
143
wenzaiquan199 OP @amon
我不知道是我没表述清楚还是什么，我没说测试发现这个问题有问题，安全这是一个大问题，但是这是一个 bug ，难道我要来个 base64 糊弄一下么，这是需要完整方案的东西和规范的，要不要加密？怎么加密？加密到什么程度？ 所以我跟她的态度就是这个不是 bug ，是个大东西，这次我修复不了，她不肯，一定要我这次加，我说你一定要我加，去找前后端 leader 给我方案，安全相关的东西我负责不了，经验不够 然后前后端 leader 开始吵了，后端 leader 的观点是，前端不需要，https 保证了大部分安全的场景，后端方面加密数据给前端就行了，而且我们一没规范，二人员少（开发团队前端+测试+后端+2leader 总共 7 个人），要搞这方面的东西话投入太多，取舍的话就是没必要 前端 leader 也在那吵，说要，一定要，但是拉着后端老大吵了半小时什么技术方案不给，说来说去就是 https 就不安全么巴拉巴拉，我能怎么怎么破解，最后后端老大不想理前端老大，然后前端老大跑到我们前端面前说我们前端没安全意识，我就烦了，他自己一直没出什么安全方案规范，甚至公司的项目混淆没混淆都不知道，最后丢到我们干活的头上，我就回了 |
 |
144
zjuster 2022-09-01 11:59:03 +08:00
1. 你们没有产品经理吗，这个让他定就好了啊。
2. 你的工作方法不对，能团队内部搞定的事情，就不要让这么多人掺和。 你看看这种方式是不是更合理： a. 测试提不要明文（身份证、电话、银行卡这种固定格式明文一眼就看出来是什么数据。你用 base64 加一些混淆编码，肉眼是识别不出来的。） b. OP：这样的改动要增加工期，你咨询过产品了吗，他要不要？； c. 产品或者测试说要； d. 跟自己的领导沟通，这个需求用啥“加密”，base64 行不行，让他知道这个事情，大概率他会说你自己定； e. 反馈给测试和产品，有加密了； f. 他们认可那就结束了，改动又不大；他们不认可，再让前后的 leader 进来定加密方案。 你的沟通方式，让后端和测试对你都有印象都差（推三阻四，不好沟通），最严重的是让你领导对你大减分。 3. 正如上文所说，身份证、电话、银行卡这种固定格式明文一眼就看出来是什么数据的，尽量不明文，应该有这样的意识。 |
 |
145
kinge 2022-09-01 11:59:07 +08:00
加密流程只要保存好密钥就行,比如前端公钥加密,后端私钥解密.代码公开也无法解密.
|
|
146
wenzaiquan199 OP @zjuster
我没说清楚，看 143 楼回复 |
 |
147
AoEiuV020CN 2022-09-01 12:13:16 +08:00
安全不绝对等于绝对不安全？
就随便加个密，AES 甚至 base64 都好，哪怕中间人理论上可以破解，安全性的提升也是实打实的， |
 |
148
SteveWoo 2022-09-01 12:47:36 +08:00
产品最终是要交给金融、政企行业去用的话， 是不允许敏感信息 [明文] 的。https （ tls ）实现传输的安全。
请求过程随着项目迭代，后续可能经过很多层，前端的请求拦截， 后台 tls 代理的透传后都可以获取明文，增加了风险。 另外，你还可以建议测试人员测试后台日志输出，敏感信息要脱敏打印。 |
 |
149
xingguang 2022-09-01 12:57:05 +08:00 1
@zjuster 不要明文应该是需求，不应该测试提，base64 也需要后端支持的，否则后端获取 base64 数据没解码肯定没法用，所以这个问题不管怎么样都不是只有前端能解决的问题，这个问题抛到 leader 哪里一点问题都没有，为什么叫推三阻四不好沟通呢？
|
 |
150
janyin 2022-09-01 13:05:09 +08:00
QA 有安全意识不错。 一般来说这应该是 security 应该管的 如果要加密也应该是让 leader 去做
|
 |
151
ZHenJ 2022-09-01 13:32:37 +08:00
只能说。。做金融产品还是按合规去做吧。。尽职免责
|
 |
152
dengshen 2022-09-01 13:45:06 +08:00 via iPhone
好多测试给自己强行加戏。。。按开发需求测试验收不就完了？ 你可以提建议给产品加需求加排期 但请不要打上 bug 标签！ 有些按 bug 率计算绩效的公司 开发恨不得砍死你测试
|
 |
153
yedanten 2022-09-01 14:34:33 +08:00 via Android
http body 加密，中间层的各种 waf 直接瞎了，TM 黑客能笑死
|
 |
154
colatin 2022-09-01 14:59:33 +08:00
这不叫加密，叫数据编码
|
 |
155
lakehylia 2022-09-01 15:16:30 +08:00
我记得前端随机生成 AES 密钥，用 AES 密钥加密明文，再用后端给的 RSA 公钥加密这个 AES 密钥。把两个加密组传给后端解开，不就行了？
|
 |
156
IvanLi127 2022-09-01 15:28:41 +08:00 1
我觉得未必有必要做，想获取你数据的，能绕过 TLS ，改你网页很难么。。直接注入一段代码抄一份数据转发出去不就完了。。。还不如搞 mTLS ，谁也别信谁。
另外楼上有办法直接在线把对称或非对称的密钥传给用户的，中间人换一下不就能愉快解密了？ [什么是 mTLS ？| 双向 TLS | Cloudflare]( https://www.cloudflare.com/zh-cn/learning/access-management/what-is-mutual-tls/) 安全这东西，多套一层一般来说是多一分安全。不过希望浪费计算机资源也能像浪费粮食一样被众人认识。。。。。。。 |
 |
157
lululau 2022-09-01 15:33:50 +08:00
弱密码比没有密码更糟糕，无效的加密比不做任何处理更糟糕
|
 |
159
AS4694lAS4808 2022-09-01 16:00:25 +08:00
所以重点是类型不应该是 bug ，而是 feature （好让老板加鸡腿）？那把这个和 leader 们说清楚呗。。让他们去吵做不做这个事，应该不是重点吧。。
|
 |
161
sucai 2022-09-01 16:06:24 +08:00
看上去感觉你们前端 leader 好像很蠢，测试不按流程提 bug 他不帮自己人怼回去，这是在干嘛。他认为把加密这部分工作抢到前端做可以给你们加一点点话语权？
|
|
162
blackshow 2022-09-01 16:31:18 +08:00
@lakehylia #160 套娃没什么卵用，安全是建立在密钥存储安全和密码算法安全的基础上，算法一旦不安全了，套多少层都没用
而且 SSL 在应用层和传输层之间，套娃只能做到应用层。 不要试图发明算法或者类似这种加密的小手段，有标准协议消停用标准协议，制定协议的时候考虑的情况远比抖机灵时考虑的全面 |
 |
163
junmoxiao 2022-09-01 17:55:24 +08:00
前端加密只是为了防爬虫，防不了黑客
|
|
164
dingyaguang117 2022-09-01 23:49:04 +08:00 via iPhone
@Chihaya0824 想怎么分发就怎么分发呀，HTTPS 基于 tls 就能替代 tls 了？
|
|
165
dingyaguang117 2022-09-01 23:51:32 +08:00 via iPhone
@twl007 囧 无言以对 不想反驳了
|
|
166
dingyaguang117 2022-09-01 23:53:01 +08:00 via iPhone
这楼真能看出程序员平均水平…
|
 |
167
yeqizhang 2022-09-02 00:07:12 +08:00 via Android
看很多人说 base64 的，有些知道 base64 的不让用 base64 呢……你说气不气人……
|
|
168
Chihaya0824 2022-09-02 02:40:56 +08:00
@dingyaguang117 没，关于分发的公钥没办法可靠的验证的问题，tls 不是比较好的解决了，就随便调侃了一下。我也没说 https 就替代了 tls 了嘛（狗头保命现在都没用了嘛 hhh ） 或者你有什么比较好的解决这方面的建议嘛，我也想学习一下
|
 |
169
felixcode 2022-09-02 03:15:18 +08:00 via Android
如果用个 https 就解决问题了，为什么还有这么多公司哈希处理和存储密码呢。
|
|
171
dingyaguang117 2022-09-02 08:48:49 +08:00 via iPhone 1
@Chihaya0824 只需要套一层非对称加密就行。因为 HTTPS / TLS 中验证公钥是基于证书链的，在不受信任的电脑上会很容易被中间人攻击。但是自己分发公钥就不一样了，可以固定写在源码里，也可以单独下发。别人想中间人攻击得改你的源码（下发响应），无疑是增加难度的。 使用标准 HTTPS 别人一旦针对 HTTTPS 做中间人，所有网站都跑不掉。你自己专有的加密逻辑，工攻击者需要专门针对你的代码逻辑进行攻击。
具体实践可以参考微博登录，就是使用了 RSA 加密后传输。 |
|
172
Chihaya0824 2022-09-02 09:30:30 +08:00
@dingyaguang117 原来如此，这确实是增加了难度
|
 |
174
Depth 2022-09-02 10:34:52 +08:00
你们说的都是技术层面的，我说一点合规的，任何三方来检查，前端传递密码未编码或者加密都是扣分项，
|
 |
175
xiangyuecn 2022-09-02 10:37:23 +08:00
https 保你数据安全到达接入服务器，至于后面的安全嘛，必须靠加密保证。
不用讲中间人带来的威胁，那是 https 的事，银行的那些现代网站也没办法；要信任正常的 https 能把数据安全的传输。 就像明文密码要不要加密，是同一个问题。 你猜你的 nginx 到自己服务器是用的啥传输的？你猜有没有哪个地方把请求数据都存了一份纯文本？ |
|
176
twl007 2022-09-02 13:16:48 +08:00
@dingyaguang117 说实话 不受信的电脑为什么一定要从你的浏览器拿数据 键盘记录器之类的都多了
而且电脑都不授信了 人家拦截一下你的响应修改一下你的公钥有有多难呢 早些年运营商各种劫持还历历在目呢 甚至还有修改下载地址的呢 而且这是前端 又不是一个单独的登录用的 app 另外你写死公钥也是不安全的行为 这个也是跟安全相抵触的 只是让你的程序看起来了安全罢了 而且你在前端打算怎么校验自己收到的公钥就是没篡改的呢？ HTTPS 至少还依靠证书信任链来校验一下 你前端打算自己实现一套类似的信任链来校验你的公钥么？ 微博那套逻辑放在 https 没有普及的年代有意义 但是现在都是 HTTPS 了 如果你连 HTTPS 都不信过 那你自然也信不过现在所有的加密体系了 而且不仅 HTTPS 很多其他的协议都用的 TLS 作为加密传输层 那么你觉得其他协议是不是都得自己再套一层加密才信得过？ |
|
177
dingyaguang117 2022-09-02 13:34:59 +08:00 via iPhone
@twl007 拦截篡改你也得知道改哪儿才行。
|
|
178
dingyaguang117 2022-09-02 13:38:12 +08:00 via iPhone
@twl007 要是 HTTPS 就够了要那么多安全等级标准干什么，一个标准就够了
|
|
179
twl007 2022-09-02 13:41:22 +08:00
@dingyaguang117 而且这个问题是个死循环 不信任 https 带来的麻烦远比用户名密码大得多
刨去登录的部分 用户浏览的东西要不要加密？你要不要确认用户浏览的东西没有篡改 会不会让人直接拿到用户正在浏览的东西？ 这么做下去的话那就变成用户不要通过网络看东西了 直接抱着显示器去接着服务器看最安全？而且写所有问题的根源就是 HTTPS 不可信？ 说真的 HTTPS 真这么不可信的话 AWS S3 早就用私有协议去设计了 而不是依赖于 HTTPS 了 StackOverflow 上也有人跟你有一样的观点 反驳的观点在这里 https://stackoverflow.com/questions/3391242/should-i-hash-the-password-before-sending-it-to-the-server-side 另外就是随便设计一个看起来安全利用了 RSA 的系统就真的安全么？ TLS 的设计并不是一拍脑袋就想出来的那么简单 |
|
180
twl007 2022-09-02 14:05:56 +08:00
@dingyaguang117
安全是个体系 又不是只靠某一个技术来决定的 对于前端而言 保障数据传输中没法被人拦截篡改才是最重要的 至于要怎么脱敏 加密处理 存储这些都是后端该干的事情 远不是仅仅一个 HTTPS 就能做到的事情 而且刨去加密 授权 /鉴权也很重要啊 只不过加密反倒是所有问题里面最简单的一部分也是最成熟的一部分 才会老被人提起来 至于你不停推崇的微博 RSA 登录加密 各种爬虫模拟教程 技术解析满天飞 好像真的打算篡改也没你想的那么难吧？ 利用成熟的 TLS 远比自己拍脑袋像一个看起来安全的方案要安全的多 而且用户名密码现在越来越少见了 其他很多验证技术都在解决需要明文密码的问题 只是国内的环境根本铺不开罢了 |
 |
181
Al0rid4l 2022-09-02 15:34:44 +08:00
@m2276699 「非绝对安全就不做」我不知道你从哪里理解出这样的意思？这是你说的, 不是我说的.
为了安全, 一个好理由, 你可以什么都做, 也可以什么都不做, 也可以做一部分, 问题是, 这个职责的边界在哪里? 楼主的场景里, 为什么只要求对这个接口做加密? 为什么别的不做? 觉得内网日志会记录敏感信息, 为什么不让运维改? 觉得会有内鬼要不要再整个零信任环境? 觉得用户机器可能被装自签证书, 那要不要干脆界面上再弹个窗提示用户检查机器安全性? 这些都是能提高安全性的, 提一点是一点嘛, 反正没有绝对安全 安全是一个整体, 不是不让做, 是让这个测试用文档形式把理由说清楚, 为什么要做? 为什么只让前端做? 这不难吧, 不然只凭测试一句话口嗨, 好让自己 KPI++? 那这不是自欺欺人是什么? 那你测试今天能一句话提这个需求, 明天就能一句话提那个需求 |
 |
182
cwaken 2022-09-02 18:54:57 +08:00 via iPhone
你就 http 传输的数据加个盐，双方皆大欢喜
|
|
183
dingyaguang117 2022-09-03 00:43:52 +08:00 via iPhone
@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. |
|
184
dingyaguang117 2022-09-03 00:49:31 +08:00 via iPhone
|
|
185
twl007 2022-09-03 13:38:39 +08:00
@dingyaguang117 因为你没看底下的评论罢了
RSA over HTTPS 的方案也不是随便拍个脑袋放一个静态公钥吧？你觉得大多数人随便拍脑袋实现一个就比 TLS 设计时候考虑得更加周全么？ 何况如果 HTTPS 都被拦截了 多点时间分析你的加密逻辑返回一个修改过的公钥回去又能有多复杂…… 反过来说如果不信任 HTTPS 应该给个理由吧 而不是单纯一句我不信任你还要再去加密一下 既然 HTTPS 都不信任 那我自己实现的逻辑就能够信任了么？ |
|
186
dingyaguang117 2022-09-03 18:39:56 +08:00 via iPhone
@twl007 理由就是 plain text 传输只要攻击者做了 HTTPS 中间人就是无差别攻击，做了任何形式的二次加密就是为了抵抗无差别攻击。（当然最好的方式是用 bcrypt 这种计算量大的， 撞密码不友好 hash 算法，但是只限于密码这种无需解密原文的场景）
就算别人是针对你的网站做了逆向，也是增加了相当的难度。而且我觉得你是低估了逆向的难度，看个爬虫教程就能让破解了，是开发者能力不足。 如果觉得微博垃圾，也可以看看 Facebook 登录的加密。更不要说券商、银行等金融机构了。 |
|
187
dingyaguang117 2022-09-03 18:52:23 +08:00 via iPhone
@twl007 另外并没有说过不信任 HTTPS ，是不能绝对信任。有更高的安全需求的场景，应该在应用层做额外的安全措施。
有些行业场景下，升级的安全举措是监管强制要求做的，你不做就是不符合安全标准，是不可以展业的。 |
|
188
twl007 2022-09-03 22:25:38 +08:00
@dingyaguang117
国内这个环境 我能想到的唯一有点用处的就是在深信服之下 可能可以对抗一下他的 HTTPS 嗅探 但是一般用深信服也会强制安装公司的证书了 实际上你也很难真的去保证安全 至于说 HTTPS 无差别攻击 如果 HTTPS 真的那么容易被攻破的话 大家还是多担心一下自己的浏览内容为好 毕竟公司层面来说 你浏览的内容也不会比你的账户密码少到哪里去 而且如果密码加密的话 那你的任何表单的人和敏感信息都要加密但是我觉得楼主的 QA 只是集中关注了账户密码 对内容却视而不见 Facebook 的加密一样有人公开分析过了 文章在这里 https://hackmd.io/@Ostrym/facebook-client-side-encryption 只要你的代码要在前端展示出来 那么实际上对于信道攻击的防护只能说是有限保护 真要想完整保护还是需要靠着后端以及依赖与独立的 APP 而不是通过 web 的形式 最好结合 2FA 一起来保证安全 否则这些加密只是再是整个流程变得看起来更加安全 至于说行业场景下 另一个例子就是国内的银行很多都有自己的安全控件 每次登陆都要通过安全控件来做 但是你看一下国外的银行 很多知识间的网页登录而已 并没有要求你去装额外的插件来实现这些 你能说国外的银行这块的安全性做得比国内差么？这几年国内的隐私泄露难道都是因为前端没做密码加密引起的么？ |
Select Language