因此,当谈到安全性时,当我有一个看起来不错的想法,但似乎没有其他人在做时,我会尝试假设我忽略了一些明显或其他重要的事情。这是一个这样的案例...
这个问题的背景是我开始研究的身份验证系统。我过去曾实现过类似的系统,并且通常都围绕“盐和哈希”的事情,但我绝不是密码安全方面的专家。
由于我正在为我的用户记录中的 16 个随机字节的盐定义存储的过程中,我突然想到,如果有人窃取或以其他方式访问了我的用户数据,可能有一种方法可以减少攻击面。我的操作基于以下假设:
- 如果黑客窃取了我的用户数据,他们可以访问用户密码的加盐 +(重复)散列表示,以及加盐值本身。
- 如果黑客想要确定该密码的纯文本值,他们面前有一些蛮力劳动。
- 但是,由于加了盐,该蛮力攻击的搜索空间大大减少了。*
*我不是 100% 确定第三点是正确的,但对我来说,如果一个蛮力算法可以假设预哈希值由<8-or-so-bytes-of-password> + <16-bytes-from-stolen-salt>(或密码和盐值的类似组合)组成,那么我们'已经通过算法上显着的数量减少了搜索空间。
<这里的问题长度的强制性中间问题道歉>
因此,以上是我目前的思路,我正在考虑的解决方案基本上归结为使用关于用户的已知常量值来动态生成盐以在散列步骤期间使用。
鉴于盐值实际上不需要是加密的“任何东西”,只要它们无法猜测到需要暴力发现的程度,基本上对提供的用户名和密码进行一些转换就足够了(例如,应用一些 SHA-2 优点和专有密码),并在散列步骤中使用它?
当然,如果有人也窃取了代码,那么“秘密”盐生成是毫无意义的。 我试图实现的唯一增加的安全性是强迫黑客窃取我的数据和我的代码,如果他们想要上面第 3 点中描述的减少搜索空间的便利。
我希望我已经充分(而不是过于冗长)描述了我的问题和推理。我希望回答的具体问题是,这是否是一种存储和比较用户密码的加密(或其他)安全方法。
编辑:看来我的问题的关键点可能已经在上面的噪音中迷失了。让我试着更明确一点:
- 访问用于生成散列值的盐是否有助于对发现实际密码的暴力攻击?
- 如果是这样,那么除了数据本身之外,还要让黑客不得不窃取我的代码是否有意义?
- 动态生成盐的一般方法(使用可重现、非随机但不可猜测的方法)是否不明智?