Ask HN: 如何防止高管沉迷于复制保护？
1 分•作者: bad_boomerang•7 个月前
因为一些显而易见的原因，我开了个匿名账号。我刚开始一份短期的开发合同，注意到前方似乎出现了一些问题，我担心这可能会影响我们交付产品的能力。
这家公司面向一个非常小众的奢侈品市场销售产品，并以高价分发一个原生应用程序。公司高管们对软件每次发布后都会出现漏洞感到非常不安。问题在于，我们目前的原生应用程序架构意味着攻击者已经拥有了root权限，我们无法保护任何密钥。此外，由于特定领域的特殊原因，某些用户在某些时候总是需要远程访问。虽然我想鼓励公司最终转向我们可以保护的客户端-服务器架构，但提供远程副本的需求意味着我们所能做的就是通过“隐蔽式安全”创建一些“谜题盒子”，而攻击者破解这些盒子的成本（以他们可能的小时费率计算）比我们创建它们的成本更低。
我认为他们对这些漏洞的出现反应过度，他们正推动开发团队在软件中引入更多的检查，从而损害了生产力，甚至可能损害了软件的稳定性，但同时又未能解决问题。
为了让您了解我的担忧，举个例子：我最近和我们的一位开发人员讨论了一个依赖问题，其中一些额外的许可证检查被嵌入到用户界面中，我鼓励采用更好的组合方式，将这些检查提取到特定的层中。他们回答说：“但如果我们把所有的许可证检查放在同一个地方，这不会让破解更容易吗？”
我知道这可能是一个危险信号，我应该尽快离开，但我认为自己是一个很有说服力的人，我想试一试。他们有点老派，所以我认为需要采取一种温和的方式。在很大程度上，我想尝试将问题从一个“技术问题”重新定义为一个“社会问题”，并减少对增加“隐蔽式安全”的关注，而是更多地关注追踪漏洞的来源，从而可以通过许可协议来执行相应的后果。
因此，我恳请大家帮助我完成这项工作。我想你们中的一些人以前可能遇到过这种情况，并且拥有我可以借鉴的经验，或者可能知道我可以使用的各种资源。我脑海中浮现的一个例子是大型在线游戏公司在目标机器人或其他作弊行为方面遇到的问题，这些问题的市场价值接近于零，而试图防御的工程部门的资源却很高；以此来证明这种方法的徒劳。然而，我有点担心，考虑到他们老派的作风，游戏可能不是他们会接受的例子。
相反，如果有人对简单的混淆和/或硬件加密锁之外的“低垂的果实”有任何建议，我也很乐意接受，因为如果我也可以从他们的角度提出一些建议，从而超越典型的收益递减曲线，可能会有所帮助。
查看原文
Throwaway for obvious reasons. I've just begun a short term dev contract and I'm noticing a bit of a bump ahead that I worry might impede our ability to deliver the product.<p>The org sells to a very niche luxury market and distributes a native application at a high price. The execs at this company are extremely perturbed by the appearance of cracks of the software that appear sometime after every release. The issue is that our present architecture as a native application means the attacker already has root and we cannot protect any key, there are also domain specific reasons why some users will always need to be remote at some point. While I want to encourage the org to eventually move to a client-server architecture we could protect, the need to provide the remote copies means all we can do is create puzzle boxes via security by obscurity, that are cheaper to unlock for an attacker (in terms of their likely hourly rate) than for us to create.<p>I believe they are over-reacting to the emergence of these cracks by pushing the dev team to introduce more checks into the software and thereby harming productivity and potentially even stability of the software while also failing to solve the issue.<p>To give you an example of my fear; I was talking to one of our devs recently about a dependency issue where some extra license checks had been baked into the UI and I was encouraging better composition to extract these sorts of checks to a specific layer instead. They replied "but if we put all the license checks in the same place, won't that make it easier to crack?".<p>I appreciate this is probably a red flag and I should run but I believe myself to be a convincing person and I would like to try. They are a little old-school, so I feel like a gentle approach is necessary. For the most part I am wanting to attempt to reframe the issue from a "tech problem" to a "social problem" and focus less on adding more security by obscurity and more on tracking down where the leaks are coming from where consequences can be enforced via license agreements.<p>So I appeal to you all to help me with this endeavour. I imagine some of you have been in this sort of situation before, and have experience I could draw from, or might have knowledge of various sources I can use. The one that springs to mind for me is the issues that big online gaming companies have with aim-bots or other cheats in markets where the value of the hack is close to the zero and the resources of the engineering department trying to defend are high; to demonstrate the futility of the approach. However I worry a little, that given the old-schoolness at play that gaming might not be an example they will be receptive to.<p>Conversely, if anyone has any suggestions about low hanging fruit, outside of simple obfuscation and/or hardware dongles, this would also be appreciated, as it might help if I can also suggest something from their angle that beats the typical curve of severely diminishing returns.