2012-06-21 75 views
5

当涉及到密码安全性时,人们会达成一致的意见,比如存储密码的盐渍散列,从而对受损的模型和数据进行统计防御。混淆安全模型是否在密码安全中占有一席之地?

有些人似乎不同意与盐有关。有很多技术可以用来保护盐类,但许多专家认为它们只是对安全模型的毫无意义的混淆,随着时间的推移,模​​型会暴露出来,我发现自己不同意与此,但我可能不了解其他观点。

我不明白的是,如果你的模型受到损害,你为什么应该假设一个完全的妥协而不是部分?如果您的安全模型分布在不同的基础架构中,而这些基础架构并非同等安全,则部分妥协可能不成问题。 (如果你这样做,比如说,加密salt并从更不安全的环境中检索加密密钥)

我假设妥协并不总是100% 。我从来没有一个系统被黑客攻击过,也没有被黑客攻击过,所以我没有完整的图片。

回答

1

混淆和加密之间最大的区别是,什么是混淆可以澄清而不需要超越密码信息任何东西 - 只要你能找出数据的您正在寻找的类型,那么你就可以找到一种方法来澄清它。

与此同时,加密只能使用正确的密钥/密码/破解工具进行解密。没有这些东西的加密数据是非常安全的。

因此,混淆最多可以放慢确定的攻击者的速度,尽管它可能推迟一个确定的攻击者。在你的系统和服务器的安全性方面,你可以做很多简单和可维护的事情来加强它们以防止不那么确定的攻击者,因此在我看来,为你和你的系统额外工作而造成的混淆成本是很少合理的。

当出现一个妥协并不是100%是一个非常冒险的努力,因为你实际上认为你比你的攻击者更聪明,更清楚你的系统。你可能是对的,但如果你假设它,你错了,那么你确实是在非常严重的麻烦。您必须证明这一点,并且考虑到证明负面的问题,在妥协发生时尽可能地完全妥协,并设计系统以使它们尽可能安全,即使在总计妥协已经发生。

0

通过默默无闻的安全性,充其量是赌博。将盐储存在其他地方是否需要付费?大概。但是当你开始进入这些多步安全设置时,你必须考虑成本与奖励。我会说,如果你的应用程序需要它,你会知道它。否则,为了拥有超强安全性,在应用程序中添加更多步骤可能只会在事情出错时给自己带来麻烦。并不是每个人都需要美国国家航空航天局的系统安全。这并不是说安全并不重要。只是你需要根据你当前的环境来锻炼它。

1

如果您的模型遭到破坏,您为什么应该假设一个完全的妥协 而不是部分?

您应该始终假设安全性最差的情况。这是最安全的方法。

部分妥协甚至可能不是一个问题

也许。但你确定吗?
在您的OP中,您将基于太多假设进行分析。也许在一个非常具体的设置你的评估,部分妥协可能不是一个问题可能是合理的。
但是,你又假设攻击者不够好找到一个洞。
不要以您的安全模型为基础。

+0

您在设计应用程序安全性时必须做出假设。 – Thomas

+0

不在安全方面。您不应该。 – Cratylus

+0

@Thomas如果你认为最糟糕的,你会有一个更安全的应用程序。 – glenatron