LnTrx

LnTrx

V2EX 第 450865 号会员,加入于 2019-11-03 18:06:57 +08:00
今日活跃度排名 2482
根据 LnTrx 的设置,主题列表只有在你登录之后才可查看
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
LnTrx 最近回复了
5 小时 27 分钟前
回复了 pegasusz 创建的主题 NAS NAS 你们打开频率高吗?
不经常打开 Web UI ,但是 BT 、Syncthing 、rsync 、相册一直在提供服务
看到现在还是觉得,HTTPS 内密码只能就来解决“有坏人但又不完全坏”的场景,例如:
1. 后端人员出问题原则上什么都可以拿到。但是也许有人看到明文 log 心生歹意,但是密文 log 就不去细想。
2. 中间人出问题原则上什么都可以篡改、窃取,但是也许有中间人只会拿明文 log ,不会分析前端加密、不会篡改前端直接拿到明文。

换言之,这种方法可以增加安全性,但增加的是非常狭窄的场景。同时,给工程增加复杂性、营造虚幻的安全感也可能会降低安全性。因此,不同厂商可能会有不同的取舍。
7 小时 11 分钟前
回复了 giganet 创建的主题 NAS NAS 你们关机吗
NAS 与移动硬盘最大的区别就在于实时在线。这样就能满足数据同步、随时调取数据、PT 上传等需求。
如果没有这种需求,在可以远程启动的前提下关机也是一种折中的选项。
对于非专业用户,手机号+验证码还是最方便,国内还能顺便落实实名制。毕竟来一句密码忘了/验证器删了/Key 掉了还得用其他方法来验证。
对于专业用户,Yubikey 这种推广的麻烦点还是在于成本,基于设备本身安全芯片的 Passkey 可能会应用更广。
21 小时 57 分钟前
回复了 rambo92 创建的主题 程序员 请 [吸词] 的作者出来解释一下密码明文传输的问题
@ShuWei 增加复杂度有时也会降低安全
@maggch97 关键在于要说明对安全的提升有多大。如果只有十分细微的提升,虽然也是好事,但是这样场景数量太庞大,会给工程带来不必要的复杂度。而增加的复杂度又会反过来增加风险。
22 小时 9 分钟前
回复了 rambo92 创建的主题 程序员 请 [吸词] 的作者出来解释一下密码明文传输的问题
尝试总结一下

用户端:
恶意软件/人员有很多手段获得密码,很难想象一种只有 HTTPS 内明文才能获得密码的场景。(安全的增益太细微)

中间人:
当前移动端安装根证书很难,PC 端需要权限。如果有本事装上,那同样有很多手段获得密码。
既然是中间人,那自然可以篡改网页,从你手里明文获得密码再加密发给网站,双方都无感知。(只有当中间人坏但又不完全坏时才有意义)

服务端:
服务端的安全性根本在于维护人员的水平。维护人员安全意识淡漠,到处都是漏洞,单单密码加密意义不大。
无论前端有无加密/散列,服务端数据入库都需要再做处理。只依赖前端加盐的安全性还是很有疑问。
在某些特定场景,例如网友说的内部人员打 log 出密码。如果是密文可能懒得研究,如果是明文可能会心生歹意。在这种
情况下,加密也许存在一定意义。
23 小时 1 分钟前
回复了 rambo92 创建的主题 程序员 请 [吸词] 的作者出来解释一下密码明文传输的问题
关键要讲清楚,前端加密的目的是什么,要防止什么样的攻击/泄露。对于用户侧的攻击,找不要有意义的场景。对于服务侧,因为会有很多环节,加一层防止意外泄露还算有那么点道理。
个人看下来:
对于用户侧,如果恶意软件/人士已经掌握足够权限,那再 HTTPS 内再加密也没意义。关键是要找到一种场景,HTTPS 内再加密能防住、HTTPS 防不住,且这种场景有考虑的价值。我暂时没还想到。
对于服务侧,经手数据的很多环节都是能看到 HTTPS 内明文的。最典型的就是内容分发,通常 CDN 的本质就是可信中间人。如果数据流转的环节需要再加强防御,那 HTTPS 内再加密还有点意义,据要结合具体场景分析。就拿 CDN 举例,如果 CDN 是坏人,只加密密码,用户隐私、Token 等信息都是明文,那一样可以窃取信息、拿下账户、伪造信息,那加密的意义也就不是很明显。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2531 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 14:31 · PVG 22:31 · LAX 07:31 · JFK 10:31
Developed with CodeLauncher
♥ Do have faith in what you're doing.