这是一个创建于 181 天前的主题，其中的信息可能已经有所发展或是发生改变。
在隔壁 #71 #74 回复过了，但估计很难被人看到，所以单开个帖： https://www.v2ex.com/t/1043320
github 的问题也不是没被暴出来过： https://zhuanlan.zhihu.com/p/36603247
单就传输信道而言，https 能解决中间人问题，明文在这个用户前端到厂商之间的 https 信道范围内没问题。 单就 github 而言，因为有二次验证，所以即使拿到密码了换个设备也登陆不上，所以有一定合理性。但 v 站没有二次验证，用明文我个人观点不太赞成
安全不只是传输信道，传输信道中间人之外还有社工、复杂的人生场景，例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码，以后说不定做什么坏事，这就属于传输信道之外的安全场景了。
用了 https 就明文只解决信道安全问题，用明文至少意味着：
- 用户应该尽量管理好自己设备的安全
- 用户到厂商之间的 https 信道之外的处理流程上，厂商应该确保安全，例如上面引用的文章里提到的 github 爆出来的问题
另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失？
- 成本：几乎没有增加额外成本
- 收益：安全强度提高了
- 损失：安全上没损失，但厂商不知道你明文，至于厂商知道你明文有什么好处，自己脑补吧
很多人都是觉得：有人用明文，尤其是有大站例如 github 用明文，所以就是对的，根本没考虑过信道之外的安全，也没有考虑大站是否有额外的安全策略例如二次验证，也没有去统计对比，是不是所有大站都用明文、或者用明文的大站占据绝大多数，也没有去区别不同站的类型和对安全的需求等级，比如是否涉及资金安全的，例如金融类、电商类相关的接口
再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证之类的额外的安全策略？
第 1 条附言 · 181 天前
好几位说我举这个例子客户端不安全了任何手段都没意义了，但是请注意，我上面只是举例子、并不是说这个例子代表所有情况。
再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。
好些人举例子 github ，github 对安全的要求级别是低于金融、电商那些 FIN Tech ，所以刚才我看了下 Amazon 的，登陆的密码是很长的 encryptedPwd 字段，淘宝我没试因为之前看过别人帖子说也不是明文
很多人还是没想明白，多加一步非明文成本没增加、几乎可以忽略，为什么不能多加这点？我实在不理解，各位坚持明文的在倔强什么。。。
> 每次看到说要前端加密的, 都很无语, 发这种帖子说明你水平低下
@weijancc 上面这句是这位兄弟的, 你说话是真没礼貌, 那我也不跟你客气了, 送你两句话八个字:
1. 看懂再说
2. 菜就多练
再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。
好些人举例子 github ，github 对安全的要求级别是低于金融、电商那些 FIN Tech ，所以刚才我看了下 Amazon 的，登陆的密码是很长的 encryptedPwd 字段，淘宝我没试因为之前看过别人帖子说也不是明文
很多人还是没想明白，多加一步非明文成本没增加、几乎可以忽略，为什么不能多加这点？我实在不理解，各位坚持明文的在倔强什么。。。
> 每次看到说要前端加密的, 都很无语, 发这种帖子说明你水平低下
@weijancc 上面这句是这位兄弟的, 你说话是真没礼貌, 那我也不跟你客气了, 送你两句话八个字:
1. 看懂再说
2. 菜就多练
第 2 条附言 · 181 天前
道理已经列举过了
简单粗暴点从实践出发, 我就想咨询下各位坚持明文的兄弟: 为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
没尝试太多大站, 只列举这么多吧, 哪位坚持明文的来解释解释
简单粗暴点从实践出发, 我就想咨询下各位坚持明文的兄弟: 为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
没尝试太多大站, 只列举这么多吧, 哪位坚持明文的来解释解释
第 3 条附言 · 181 天前
补充一点: 标题里我少打了符号, 标题意思不是说 HTTPS 是明文, 而是指: 用了 HTTPS, 在 HTTPS 的信道之上传输的 HTTP 参数里使用明文(这个明文在 client 端和 server 端而言都是明文)
第 4 条附言 · 181 天前
@msg7086 @mightybruce
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴
你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.
所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.
> 但不是所有业务都需要那么高的安全级别，再直白一点，有成本
@iyaozhen 安全级别的问题确实是关键, 并不是所有站都需要这么高的安全级别. 但成本这个我不太赞同, 因为简单的不使用明文只需要哈希盐一下, 我觉得很多站不用, 是因为不需要那么高的安全级别+历史惯性+认知, 例如帖子中很多坚持明文的人的认知
> 为什么你会这么想？很简单，你的逻辑思维能力不行。
@LandCruiser 说不礼貌的话之前, 建议先看懂别人是什么意思再说
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴
你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.
所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.
> 但不是所有业务都需要那么高的安全级别，再直白一点，有成本
@iyaozhen 安全级别的问题确实是关键, 并不是所有站都需要这么高的安全级别. 但成本这个我不太赞同, 因为简单的不使用明文只需要哈希盐一下, 我觉得很多站不用, 是因为不需要那么高的安全级别+历史惯性+认知, 例如帖子中很多坚持明文的人的认知
> 为什么你会这么想？很简单，你的逻辑思维能力不行。
@LandCruiser 说不礼貌的话之前, 建议先看懂别人是什么意思再说
第 5 条附言 · 180 天前
刚开始我没理解为什么那么多人还要坚持明文, 这两天 get 到一些了, 我琢磨可能是因为, 很多人自己这样用了习惯了, 所以这是属于舒适区, 人的天性就是难以从舒适区里出来
外加经济学上的"沉没成本效应", 因为自己学习领会了一些 https 和加密等领域相关的知识, 就使用这些知识点头疼分析头脚疼分析脚, 只管自己处理的环节, 从而忽略了整体流程上包括社工之类的的完整安全
外加经济学上的"沉没成本效应", 因为自己学习领会了一些 https 和加密等领域相关的知识, 就使用这些知识点头疼分析头脚疼分析脚, 只管自己处理的环节, 从而忽略了整体流程上包括社工之类的的完整安全
228 条回复 • 2024-10-25 23:23:35 +08:00
 |
201
lesismal OP > 谁出钱谁说了算。你出钱吗？你不出，所以你说了不算。
公开的技术讨论, 各自公司自己的事情自己负责, 你看见我什么时候说过我说了算了要求你们所有人都要按我说的做了? 但是, 我公司的项目就是我说了算, 你也管不着 > 你自始至终都没有对 Before 和 After 做过具体的案例分析，帖子里基本就是一些假大空的呐喊，什么坚持明文啊什么舒适区啊什么天性啊。怎么不上点干货呢。 哦哦, 和着我说的技术逻辑安全逻辑安全原则和举例子之类的, 都算是假大空是吧? 我说了那么多逻辑原则例子你思考吗?你不思考还狡辩解释那么多层然后被逼的我说你舒适区有错吗? > 这么高一层楼 200 来个回复，说句实话，非常给你面子了，因为讨论的过程还算礼貌，v 站大多数人也不愿意说脏话。 怎么的, 有些个小孩子上来就说"你水平低"之类的, 你见我说几句脏话了吗? 聊个技术还怕别人喷, 那就不要出来聊 > 换到激进点的论坛里，就不知道是你保卫家人在先，还是管理员看不下去直接 ban 号在先了。 自己说不过了, 就改成威胁别人要骂人了是吧? 我不 care 低素质的人, 你随意 @Livid 我感觉这是在威胁骂家人了 > 帖子内容太过贫乏，甚至激不起我一点讨论技术的欲望。有句话叫，非蠢即坏。 蠢和坏也是要以事实逻辑为依据, 我每一个点都有对应的解释, 如果你看不懂然后以为我蠢, 那你也随意, 你嫌烦的话可以直接 block 我 > 看你讨论过程，好像也不像是坏，那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的，有一种老子说的才是对的，你们不同意那一定是你们都是傻逼。那这就没法聊下去了。 你看看你这两层的回复, 谁在假大空? @msg7086 |
|
202
lesismal OP @viruscamp
我已经发现了, 讲的原则逻辑和道理各位基本都不怎么看, 所以我举例子请教各位, 淘宝亚马逊不用明文, 是为什么? github 日志输出明文的问题暴出来大家也"多数人"认为这是问题, 为什么? 我这里说"多数人"而不是说"所有人"认为这是问题, 因为我发现可能并不是"所有人"认为这是问题, 比如各位坚持明文的 |
|
204
lesismal OP @msg7086 虽然可能 block 我了, 但说不定你 logout 能看到, 所以补几句吧, 你让我举例子, 我说黑产黑了的很多没曝光出来你又说我假大空, 那你可以看下 github 的例子, 可以看下 #158 cdn 脱裤的例子, 淘宝亚马逊以及#174 微信的推荐设计
自己脑袋一热也不认真分析下我的回复, 就无脑喷我, 只会限制你提升自己的技术层次, 这跟我所理解的原因(病因)八九不离十, 就是舒适区和沉没成本, 另外一个词就是"聪明反被聪明误", 因为自己懂了一些, 所以拒绝接受不一致的. 但技术需要冷静分析, 论坛上讨论技术我多数时候是一就是一二就是二, 不喜欢模棱两可去赞成别人, 所以我的观点如果和你不一样的时候, 你可能会觉得我带着情绪, 但不是, 技术的东西是实在的, 谁也不给谁发工资, 不需要看脸色 |
 |
205
Hawthorne 179 天前  1
明文的问题是，你泄露的不光是这个密码，而是你密码的生成范式。
而且，如果每家网站的客户端生成的密码 hash 不一样，你甚至可以全网使用同一个密码。 |
 |
206
testcaoy7 179 天前 1
我也是不赞成传输密码明文的，HTTPS“并没有”许多人想象地那么安全，尤其是国内环境，很多人并不会注意系统里面的 CA 证书，而不少软件都会在安装过程中在系统 CA 里面加料。
这也是为什么网上银行密码需要单独安装独立文本框控件，大额转账需要 U 盾之类的电子密码器的缘故。 许多人将银行的系统视为技术老旧，心中颇有微词，其实银行那样是有道理的。目前我发现的趋势是，越是喜欢炫技的网站、产品，出问题越是多。 |
 |
208
llsquaer 178 天前
讨厌一个句话 “你电脑本身不安全了，就不用再考虑安全”。
不知道谁说的， 典型的就是之前讨论 Chrome 可以本机自由的导出历史记录，保存的密码。然后就有人解释说了上面一句话。 但是在我有限的理解来看，Chrome 不是应该自己在加一个密防止导出么？ |
 |
209
maplefly 178 天前
我只能说如果经历过红蓝对抗，那么只要你传输没有加密，就会被通报
|
 |
210
zlowly 178 天前
我觉得楼上很多人对数据安全问题还是了解有限，如果你不是这里数据安全领域里摸爬滚打过，就不要轻易下结论。如果你身边有参加过 HW 的，或者打过 CTF 的同学同事，先去和他们请教一下 HTTPS 用明文传输密码的风险，了解一下为何有了你们都觉得安全的 https ，在 CTF 里还是有 wiresharp 分析 https 流量的赛题。
|
 |
211
zanpo 178 天前
https 用明文传输有啥问题，假设我使用 https 明文传输密码，客户端安全，TLS 握手时校验服务器证书，你能在网络传输的节点截取我的数据能看到明文吗？ 你界定了使用 https 明文传输密码就不要扯东扯西。只需要讨论在传输过程中你如何截取到我的 https 明文数据就行了。
你的所谓例子没有一点意义，客户端不安全有啥好讨论，我种个马拦截键盘输入，你明文密文传输有区别？你输完密码，我 F12 调编辑框属性我看不到你的密码？你输入密码，我调试程序，内存里面看不到你的密码？你明文密文传输有区别？服务器不安全有啥好讨论，你密文传输，服务器端不照样解密，内存中存在明文密码？服务器不安全，你明文密文传输又有何区别？ 本来 https 就是基于 TLS 的传输层安全协议，假设你可以在我和服务器中间的任意路由节点上拦截到数据，你只需要告诉我怎么从 https 数据中拿到明文密码就行了。 |
 |
212
liuminghao233 178 天前 via iPhone
你的意思把密码 hash 一下就感觉安全一些
再 hash 一下感觉又更安全了是吧 实际上没有提升安全等级 解决安全问题的是 2FA ，而不是你所谓的“明文加密” |
 |
213
iyaozhen 178 天前
@zlowly 看你说的 我自己也想了下。虽然在大公司，但很多时候都是螺丝钉， [身边有参加过 HW 的，或者打过 CTF 的同学同事] 真的很少。业务部门也就有安全工单的时候和安全部门有接触。倒不是说不关注安全，功能开发能按安全 SOP 做好就已经打败 90%的人了
|
|
214
zlowly 178 天前
要从 https 数据中拿到明文密码，一种可行路径是：扫描关键服务器的信息泄漏漏洞->获取服务器私钥->攻击服务器侧其余薄弱服务器（如测试环境）->横向渗透或抓取服务器段流量->解密服务器 https 流量。通过此途径，可以在没有取得关键服务器的管理、修改权限的情况下，仅凭中风险漏洞就能从流量中获得用户密码等信息。
还有更多其它方式。现在复杂的部署环境，我觉得大部分人都只能负责一小块，服务器、网络、WAF 、负载均衡等等不可能都完全由你掌握，例如有些设备由于性能还要求你先卸载 SSL ，光靠 https 一劳永逸不实际。 也许你会认为这是服务器安全加固责任之类问题，和 https 无关，但是在 HW 、会议等敏感时期中一旦出现安全事故，保不准哪位哥们为了减轻责任，就是把你密码明文传输赖上，为了撇清责任你的上级也不一定会为你说话。 是的，HASH 一下它还是有其它风险，但我自己觉得，多做这一步，不是为了保护数据，而是为了不用提桶跑路。 |
 |
215
forty 178 天前
@zanpo CDN 现在挺普及的，用户是跟 CDN 通信，CDN 再跟服务器通信，CDN 其实是中间人，所以有时候你需要让通信内容不被 CDN 知道，就需要多加密一层。比如，敏感内容，你不想被 CDN 检测和谐。
|
 |
216
hesetiema 177 天前
|
 |
217
xxxccc 177 天前
@cndenis 不对吧，当年 csdn 的数据库被扒了，里面存储的用户密码就是使用明文的，导致不少有些人的其他账号也受到影响。
https://baike.baidu.com/item/%E5%AF%86%E7%A0%81%E5%A4%96%E6%B3%84%E9%97%A8/4976608 |
 |
218
iseki 176 天前 via Android
@lesismal 明文向后端传输虽然不好，但有时这是工程上成本刚好可以接受的方式。一来我刚才说了，很难设计一个有足够收益的非明文传输方案，二来就是有时候后端的某些设施只能接受明文。
|
|
219
lesismal OP @zanpo 兄弟你根本就没看懂 OP 我说的是什么, 你们好些位这都相当于是盲人摸象管中窥豹, 只考虑 https 或者某个 part, 请先看下我帖子和 append 或者更多楼层的回复
|
|
220
lesismal OP > 明文向后端传输虽然不好
你看, 你也认为明文不好了 > 但有时这是工程上成本刚好可以接受的方式 如果是项目初期/上线前, 这个成本真的不多 > 一来我刚才说了，很难设计一个有足够收益的非明文传输方案 数据隐私本身不重要的网站, 明文与否都还好, 即使泄漏了也没关系. 我自己注册一些不重要的网站的密码都非常简单, 单手输入满足大小写之类的就用了, 也不怕泄漏, 重要信息的网站就复杂些而且那些站多数有二次验证之类的额外安全措施, 所以也不怕 > 二来就是有时候后端的某些设施只能接受明文 密码这个功能点上来讲, 明文不是必需, 所以如果哪家说必需明文, 那我怀疑这是别有用心... @iseki |
|
221
iseki 173 天前 via Android
不是，举个例子 LDAP 登录，这是很常见的需求。业务逻辑是尝试使用搜索到的 DN 和用户提供的口令 Bind ，Bind 成功即为认证成功，这就必须把用户输入的原始口令发送过去。
|
|
222
lesismal OP @iseki LDAP 我没太了解过，但如果它需要明文的密码，这应该也是历史遗留问题，因为本质上是不需要明文的。另外，“必须把用户输入的原始口令发送过去”—— 这里的原始口令要看是哪种，如果是密码、那是历史实现问题和现在的兼容性、修改成本问题，如果是 OTP 这种单次验证码，则没关系，单次的验证码明文也可以、不怕泄露
|
|
223
lesismal OP @lesismal #222 不要看它当前是什么方式，站在当前实现的方式的角度考虑问题则任何现状都有它局限于历史和版本等问题导致的合理性。应该撇开历史现状，看理论和实现方法上，哪种方式可以做到更好。是否把旧系统改造升级是项目自己的管理的问题
|
|
224
iseki 168 天前 via Android
@lesismal 按这种讲法就没什么可讨论的了。一切当然是可以改的，就算是碰到必须获取原始口令的设施你也可以说改造旧设施，那还有什么可说的呢。
|
|
225
lesismal OP @iseki
什么情况必须获取原始口令？密码和 OTP 是有区别的，你要说 OTP 我没意见。其他系统的密钥本身，我暂时想不到必须用原始明文口令的。 我的出发点是，实现各种密码存储需求本身要应对的业务，并不需要以来明文本身，历史问题是历史问题，但这里说的是方案本身的优劣，历史改造甚至都不在我考虑范围内 所以这根本不是说法的问题，是逻辑本身的问题，如果你一定要用“现在已经有哪些使用了明文、所以避免不了用明文”来讨论，那确实没什么可讨论的了，这不是我在讨论的问题 |
 |
227
littlez0325 26 天前
@csrocks 前端 hash 后传给你的是 hash 值,你还按之前的 md5(password+salt+password)摘要方式得到 md5(hash+salt+hash)的摘要值不就行了,并不是说把你的摘要算法放到前端去,然后你就不做了,前端可以用 sha1/sha256/PBKDF2 等等摘要算法计算摘要值,只要各个前端都统一加上就行,都是现成的摘要算法,接入根本就不需要什么成本,最大的成本还是项目刚启动时就都没有这个意识,后期改动会造成旧密码不能用,或者要加兼容逻辑
|
|
228
littlez0325 26 天前
本质是防止原始密码被人知道,不用可逆加密算法,而是用不可逆摘要算法
直接把用户输入的密码按照一定的规则生成一个 salt(比如把密码的字符每 n 个字符删除一个,然后用 md5 或其他算法生成一个摘要值作为原始密码的 salt),然后 PBKDF2 算法生成一个摘要值传给服务端,服务端无法知道原始密码,也不需要知道,直接用传过来的摘要串做后面的逻辑(用加盐摘要算法生成摘要串落库/前面的方式对前端传过来的摘要串操作后和库里的对比是否密码正确) 1.密码强度验证逻辑没必要放在服务端,不会有人要对强制绕过前端逻辑直接传弱密码到服务端的用户负责吧 2.撞库不存在的,不会有服务端允许一个用户一直用错误密码尝试登录而不限制吧 3.数据库泄露的话,密码存的也是摘要值,完全可以每个用户一个不同的 salt(自定义的规则串,不用落库,比如用户的用户 id/创建时间等注册后就不变的字段按照一定的规则拼接,再加上一个服务端代码里的固定 salt 串,随你发挥,保证每次要校验用户密码时能拿到就行 salt 所需的信息就行),攻击者想碰撞就碰去吧 |
Select Language