流行的安全“货物崇拜”

信息安全 安全剧院
2021-08-11 09:20:08

在信息和 IT 安全中,有一种令人讨厌的趋势,即特定的“最佳实践”成为不可侵犯的黄金法则,这导致人们建议无论它们是否适合特定情况(类似于Cargo Cult Programming)都可以应用它们

这方面的一个很好的例子是密码策略的常见方法,它应用一个大小适合所有 8 个字符长度要求并结合高复杂性要求,12 个以前的密码存储在历史记录中以停止重复使用,3 个错误尝试锁定和 30 个日轮换。

30 天轮换旨在降低攻击者使用被盗密码的机会窗口,但它可能会导致用户使用序列密码,这意味着如果攻击者可以破解一个实例,他们就可以轻松解决其他实例,实际上是逆转预期的安全利益。

高长度和复杂性要求旨在阻止暴力攻击。结合合理的锁定策略和入侵检测可以更好地缓解在线暴力攻击,离线暴力攻击通常发生在攻击者破坏包含密码的数据库时,并且通过使用良好的存储机制(例如 bcyprt、PBKDF2 ) 还有一个意想不到的副作用是它会导致用户找到一种有效的模式,并且还会增加用户写下密码的风险。

3 不正确的锁定策略旨在阻止在线暴力攻击,但将其设置得太低会增加帐户锁定和超载帮助台,并且还存在拒绝服务的风险(许多在线系统很容易猜到用户名结构,如 firstname.lastname,所以很容易将用户锁定)

还有哪些 Cargo-Cult 安全性通常应用不当的例子?

4个回答
  • 闭源比开源更安全,因为攻击者可以查看源代码并发现和利用漏洞。 虽然我并不是说这总是错误的,但对于开源软件,外部专家至少可以审查软件以寻找漏洞/后门,然后公开修补它们。使用封闭源代码软件,如果不煞费苦心地反汇编二进制文件,这是不可能的。虽然您和大多数攻击者可能无法访问源代码,但可能存在强大的攻击者(例如,美国政府),他们可能能够获取源代码或向其中注入秘密漏洞。

  • 如果您对数据进行加密,通过网络发送数据是保密的加密需要经过身份验证,以防止攻击者更改您的数据。您需要验证您向其发送信息的另一方的身份,否则中间人可以拦截和更改您的流量。即使有身份验证和识别,加密也经常会泄露信息。您通过 HTTPS 与服务器通信?网络窃听者(您的 ISP 的任何人)确切地知道您发送了多少流量、发送到哪个 IP 地址以及每个响应的大小(例如,您可以根据传输的所有资源的大小对各种网页进行指纹识别)。此外,特别是对于 AJAX 网站,您输入的信息通常会导致服务器响应,该响应可通过其流量模式来识别。Web 应用程序中的侧通道泄漏

  • 弱密码重置问题- Sarah Palin 的电子邮件是如何被黑的一个人通过了密码重置程序,可以从公开信息中正确回答每个问题。facebook 熟人能解决哪些密码重置问题?

  • System X 是牢不可破的——它使用 256 位 AES 加密,可能需要 10 亿亿亿年才能破解 10 亿台普通计算机。 是的,它不能被暴力破解,因为这需要大约 2 256次操作。但密码可以重复使用或在常用密码字典中。或者你在电脑上卡了一个键盘记录器。或者你用 5 美元的扳手威胁某人,他们告诉你密码存在侧信道攻击。也许随机数生成器有缺陷存在时间攻击。存在社会工程攻击。这些通常是最薄弱的环节。

  • 这种薄弱的做法对我们来说已经足够好了,我们没有时间等待安全地做事美国政府不需要担心加密来自无人机的视频馈送——他们会知道要收听正确的载波频率;除了加密盒会很重而且很贵——何必呢?

  • 量子计算机可以快速解决指数时间问题,并将破解所有加密方法人们阅读有关量子计算机的科普文章,并听说它们是这些神秘的超级强大实体,它们将利用近乎无限数量的平行宇宙的计算能力来做任何事情。这只是部分正确。量子计算机将允许通过 Shor 的算法在多项式时间 O(n 3 ) 内完成因式分解和离散对数,从而使 RSA、DSA 和基于这些陷门函数的加密很容易破解。类似地,量子计算机可以使用 Grover 算法来暴力破解密码,该密码应该花费 O(2 N ) 时间,只需要 O(2 N/2) 时间; 有效地将对称密钥的安全性减半——众所周知,Granted Grover 的算法对于量子计算机来说是渐近最优的,所以不要指望进一步改进。

一些例子:

  • 更大的钥匙。4096 位 RSA、256 位 AES...更多位总是更好。(请参阅评论:没有必要让密钥大于确保“根本无法破坏”状态的大小;但更大的密钥意味着网络和 CPU 开销,有时是大量开销。)

  • 自动执行“安全函数”,例如snprintf()代替sprintf()(除非程序员测试可能的截断,否则它不会有多大好处,并且不会阻止使用用户提供的字符串作为格式字符串)。额外的分数strncpy()并没有像大多数人认为的那样(特别是,它不能确保最终的分数'\0')。

  • “安全管理器的纯度”。作为职责和角色分离的一种应用,所有“与安全相关的”决策都应该由不同于项目设计者和开发者的安全专家做出。经常被带到被误导的极端,决定应该在任何防火墙上打开哪些网络端口的人对项目一无所知,并且故意拒绝学习这方面的任何东西,因为独立决策知情决策更重要。

我将添加我自己在咨询时看到的 appsec 示例:

  • “我会通过电子邮件向您发送一个加密的 zip,并在同一封电子邮件中包含密码……”这不止一次发生在我身上。如果您将钥匙留在门内,上锁的门将不会保持锁定状态。
  • “但你不可能得到 SQL 注入SMTP 注入,我们呼吁 sanitize()一切!”。没有办法让变量在每次使用时都安全,您需要使用卫生程序来完成这项工作。
  • “我们不能被黑客入侵,因为我们只使用 XXX 平台/语言/操作系统”。每个平台都有安全问题, 时期
  • “我们每年都有一次安全评估,你什么也查不到。” 频率!=质量经常进行评估是一件好事,但这并不能保证任何事情!
  • “我们有一个 WAF,这意味着我们不必实际修补任何东西。” 是的,所以这发生了……我有一个客户端没有修补已知的 CSRF 漏洞,因为他们认为 WAF 能够阻止这些攻击。(没有WAF可以做到这一点。我曾经发现一个WAF声称它可以“阻止所有的owasp top 10”,并且WAF的HTTP管理接口容易受到CSRF的攻击。)
  • 密码在存储到数据库之前必须经过加盐和哈希处理。SHA-1 非常适合,SHA-512 非常适合。

我仍然从许多安全专业人员、安全培训和当前的安全指南中听到这一说法。