我正在用 C# 开发一个 Windows 窗体应用程序。我听说一个人不应该在代码中使用内置方法和函数，因为黑客对这种内置方法有深刻的理解，并且知道如何使它们失败，而是应该始终使用他/她自己的函数和方法，如果不是，则从那些新创建的函数中智能地调用内置函数。这有多少是真的？
支持我的论点的一个支持示例是，我看到开发人员总是开发自己的加密算法，如 AES、DES、RC4 和 Hash 函数，因为他们认为内置加密算法中有很多次后门。
问问题
96 次
2 回答
4
除非您知道应用程序将使用的内置方法的特定故障模式或弱点，并且知道如何最小化或消除它们，否则最好使用语言或库设计者提供的方法，这通常会更比普通程序员为特定项目即时想出的方法更高效、更安全。
您的示例绝对不支持您的观点：开发自己的加密算法，而无需在该领域有一些严肃的背景并由密码分析人员审查，然后在安全关键代码中使用它，这是灾难的根源。即使开发自己的行业标准加密算法的自定义实现也可能会出现问题，如果您没有经验，几乎肯定会出现问题。
于 2014-04-20T09:33:58.173 回答
4
什么？！不不不！谁告诉你这是错误的。
有一个常见的谬误是，发布的源代码更容易受到“h4ckerz”的攻击，因为任何人都可以发现其中的缺陷。但是，我很高兴你提到了加密，因为这是这个推理线真正存在的领域像谬论一样。
https://security.stackexchange.com/上有史以来最受欢迎的问题之一是关于一个开发人员（在 OP 中他被赋予了化名“Dave”），他分享了对已发布代码的恐惧。戴夫，就像您看到的开发人员一样，正在尝试自制自己的加密算法。这是该线程中最受欢迎的评论之一：
Dave 有一个根本错误的前提，即算法的安全性（甚至部分地）依赖于它的模糊性——事实并非如此。散列算法的安全性依赖于我们对数学理解的局限性，并且在较小程度上依赖于硬件暴力破解它的能力。一旦 Dave 接受了这个现实（这确实是现实，请阅读 Wikipedia 关于散列的文章），这是一个谁更聪明的问题 - Dave 自己，还是一大群致力于这个非常特殊问题的专家。（重点补充）
事实上，就目前而言，Security.SE 上的前两个模因是“不要自己动手”和“不要成为戴夫”。
虽然这都是关于加密的，但这通常适用于大多数开源软件。后门被发现和修复的机会随着每一对代码的新目光而增加。这应该是一个简单且没有争议的前提：寻找的人越多，被找到的机会就越高。是的，这适用于寻找漏洞的恶意用户。然而，它也适用于高级用户、白帽黑客、安全研究人员、密码学家、专业开发人员和其他为“好”工作的人，这些人通常（希望）超过为“邪恶”工作的人。这也隐含地依赖于黑客需要的错误前提看源代码做坏事。这显然是错误的，基于源代码从未发布过的专有系统的绝对数量（想到各种 Microsoft 和 Adobe 程序），这些系统多年来一直被漏洞淹没。也许阅读源代码会使黑客的工作变得更容易，但也许不是——更容易仔细研究源代码以寻找攻击媒介，还是仅使用扫描工具和脚本对已编译的二进制文件进行扫描？
tl;博士不要成为戴夫。自己动手意味着你必须在每件事上都做到最好才能取得成功，而不是对社区提供的最好的东西进行抽样。
心脏出血
在您的评论中，您反驳：
那么为什么[较早]没有找到并纠正 openSSL 中的 Heartbleed 错误？
因为没有人看它。这就是可悲的事实。这就是区别——一旦有人找到它会发生什么？现在，成千上万的安全研究人员、加密专家和其他人正在研究它。假设我之前提到的一个专有产品中存在相同类型的漏洞，它很可能存在这种漏洞。一旦被抓住（如果被抓住），问问自己：
- 现在，公司的程序员团队能否从整个全球安全专家、密码学家和其他分析师社区的帮助中受益？
- 如果在您的软件中发现了一个如此严重的错误（这是一个很大的问题！），您是否准备好处理由您的自定义实现引起的后果？
于 2014-04-20T09:34:25.500 回答