FrankHB 最近的时间轴更新
↓挽……
228 天前
FrankHB

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
FrankHB 最近回复了
@JohnBull 这哪来的设计初衷?又哪看出了 OP 要的是配置文件的功能?
照你的说法是不是 Windows 系统属性里设置环境变量的界面也是违反初衷,该改用配置文件?
(要是非得把注册表当配置文件,行吧,当我没说。)
@opentrade 写文档不是文化,而是工程师的本职工作。文档是标准化工程流程的主要接口和交付物之一,不管这个文档会不会交付到客户手上。
至于实现产品的反而不需要是工程师,甚至未必是人——比如 copilot 都能凑数。
第二篇文章中“密码管理器存储主密码”是个词不达意的错误翻译。
原文相关段落:
Some applications stored the entered master password in plaintext or implemented hard-coded crypto keys in the program code. Consequently, attackers can easily circumvent the crypto algorithm altogether and thereby gain access to all of the user’s data.
很显然如何存储和访问都有更明确的限定。

不过,TeamSIK 的这个说法也是有问题的。
现实中最显著不安全因素来自用户对系统错误的安全假设,而替用户定义什么叫 security 是造成这个现象的原因之一。
具体来说,原文中隐含假定理想的密码管理器总是应当且能够保证不泄漏敏感信息,给用户以错觉认为密码管理器能提供保密保证,然而这就是体系上的重要潜在漏洞——仅仅是方便方案提供者甩锅而无助于实际确保安全性。另一个更常见的可比的例子是鉴权者无原则要求强口令的密钥策略,导致不少用户倾向于以不安全的方式另行储存密码,凭空增加攻击侧信道,反而引起更大的风险(讽刺的是,密码管理器在一定程度上就是为了应对这种问题而被发明的)。

安全系统想要达到的一个主要根本目标是:让理解安全的用户得到预期的安全属性。获取用户数据并不总破坏这种属性,例如考虑用户可以极低成本地有意投毒而愚弄攻击者。
当然,极端的安全系统玩家可以不在乎这种密码管理器的限制问题(若有,也可以自己实现密码管理器,这至少发明现实可靠的加密算法容易得多)。而对大多数密码管理器的用户,他们仅仅需要一种把密钥视为最需要避免泄密的数据而容易访问的方案。但这个意义上,如何存储主密码也不是什么大不了的问题了——尽管用明文、硬编码加密的代码和真正的密码(cipher)具有密码学强度上的显著不同,攻击者一旦获知主密码就可以访问所有敏感数据的这点不会有差异——注意主密码可以被密码管理器“存储”阶段前截获。要修补这里的缺陷,需要用 2FA 等方式代替单一的固定口令。不过,这又增加了使用的困难,削弱易用性和灵活性,而在另一方面同样可能增加前述的风险。
作为实用解决方案,密码管理器应当把容易做的事情做好,而不是妄图面面俱到。这个意义下,花费较小的代价而明确减少显著的风险的设计是“好”的——包括避免使用明文存储主密码。但是,鉴于密码管理器不是入侵检测系统也不需要实现访问权限控制,它的“管理”行为并没有在字面上必须提供对主密码的反泄密存储保护(作为和用户的接口约定),即便退到这个地步,不合理的主密码存储方案仍然是个实现质量(QoI) 问题,而不是所谓的 security vulnerability 。真正的漏洞直至用户错误地信任密码管理器会提供这种保密才会形成——尽管这种错误信任非常普遍,远甚于这里强调的对开源密码管理器的无原则的信任。

另一个更现实的例子是 Chrome 通过明文保存密码: https://www.v2ex.com/t/872745 。这里,Chrome 的实现也不算是严格的安全漏洞,因为一个应用程序假定一个多用户宿主系统提供正确实现的访问控制是合理的,对文件系统的访问控制的正确实现是宿主系统的职责,正确利用系统提供的访问控制排除非预期访问是用户的职责,两者都不是 Chrome 需要关心的本职工作,所以 Chrome 的维护者的确有理由拒绝承认这是功能缺陷。但是,无论是宿主实现的安全性不可保证(乃至不可审计),还是用户普遍缺乏安全意识的现实,都使不确定的攻击更容易实现,因此这里的 QoI 问题相比 Firefox 等替代,无疑是足够显著的了。
21 天前
回复了 jsun969 创建的主题 程序员 看看程序员鱼皮的嘴脸
@FrankHB 好吧没发现链接能点进去空间……
21 天前
回复了 jsun969 创建的主题 程序员 看看程序员鱼皮的嘴脸
这谁啊很有名么……
挂一个混睿站的你好歹上个 UID 吧,否则 6 硬币又是一条好汉……
@wdwwtzy C:?
@lmshl 这个结论是菜鸡理解。
说学语言的目的是学语言特性,就跟学库的目的是学 API 一样。典型地没搞清目的和手段。
如果学语言的目的是要了解不同的范式,那么学会怎么使用特性是可以提供一些帮助,但是因为不熟练就没法确定是否顶用,这非常低效,是个不推荐的做法。
正常的做法是,直接把目的拔高到修改和制造不同的语言,然后才能方便在不同的语言特性中去重。语言特性不再需要是直接学习的对象,要学习的应该是语言规则怎么写的原因。理解了为什么怎么写,比理解具体是什么重要得多,也理应更加花时间消化。比较几下顺带还可以看出编写 spec 的作者的水平问题。
至于学会具体语言特性怎么用,那本来就是顺便。须知,大多数个别特性其实都不怎么顶用。归纳出什么特性组合顶用,无非是两种套路:一整个语言挨个儿学(因为一大抄,非常低效),要么就是自己理解怎么去组合。当你清楚怎么组合时,那自然就知道该怎么用了(或者说怎么批判不顶用)。
只有遇到实际需求叫你用哪个具体语言去实现什么东西的时候,再去考虑学整个语言——通常也不需要(因为绝大多数语言的设计者都有不少明确不求甚解的地方,设计出来的东西从没正常到值得你整个照搬去参考的地步)。
@tobeyoung 怎么不是呢,机器码编码的汇编语言也是语言,还不止一种。
只不过不是所谓的高级语言罢了。
JVM bytecode 的 opcode 和 IL 都是放在 JVMS 里讲的。就是 Dalvik bytecode ,也是同时给出运算格式和助记符语法的。Smali 反而不算一个很正式的语言,因为总结它的文法的正式文档都找不到。
如果 OP 说的是真的,那根本不需要有什么焦虑,因为高级语言和不高级的语言差的比多数不同高级语言之间大多了。
又不是没源码,直接本地重新编译链接会死?
还是说服务器连 gcc 这种都没有?
会死的话投诉服务器管理员,丫个生产环境都残的。
看你基础素质咯。
比如基础心率就能把你喝多少酒按着摩擦的,敢给我敬酒试试?
比如啥事不干日常就得头孢喹诺酮硝基咪唑伺候的,刚给我敬酒试试?

@ichubei 什么鬼,酒量大顶撞医嘱?
是不是上头了还能顶撞法医啊?
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4574 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 21ms · UTC 08:13 · PVG 16:13 · LAX 00:13 · JFK 03:13
Developed with CodeLauncher
♥ Do have faith in what you're doing.