安全是一项复杂的工作，像“明文密码？从不”就像“密码必须包含特殊字符”或“我的密码比你的大”或“如果我无法理解，没有人可以”如果你不考虑完整的上下文一样糟糕。

首先，我们来分析一下资产。有两个主体：银行和客户。他们拥有多项资产：

• 银行的钱。根据攻击者的行为，银行可能需要花钱解决问题，以补偿客户或其他方，并且可能会看到其声誉受损。
• 客户的钱（和他的私人信息）。
• 客户的密码。如果受到损害，他将需要更改它，也许在其他站点上也是如此。
• 在一个会话期间发送的身份验证数据。这可能与密码不同，例如在此处考虑的情况下，这（通常）是密码中的两个随机字符。

银行完全控制安全架构。它将自己资产的安全性置于客户资产之上也就不足为奇了。这对密码来说不是个好兆头。

密码周围有很多威胁，包括（为方便起见编号，不表示任何特定的重要性顺序）：

1. 攻击者可以访问银行的实时系统或备份，并能够以密码在存储中的编码方式访问密码。攻击者几乎肯定可以通过这种方式一次获得大量密码。
2. 攻击者获得对客户使用的计算机的访问权（例如，通过在其上安装恶意软件）并获取身份验证数据，可能会劫持会话。
3. 攻击者通过肩冲浪或其他无法控制会话的方法获取身份验证数据。

对银行服务器上的密码进行散列专门缓解威胁 #1，即未经授权访问编码密码。这种缓解是有限的，因为它只对足够强的密码有效；即使受到慢散列的保护，弱密码也会失效。

将身份验证数据与密码分开会增加对这种威胁的脆弱性。另一方面，它减轻了威胁 #3 并在较小程度上减轻了威胁 #2：拥有一个会话的身份验证数据的攻击者无法轻松地复制它以打开另一个会话。如果他多次尝试直到获得与他拥有的身份验证数据相匹配的挑战，他的尝试很可能会被银行的服务器阻止。最终，如果他观察到足够多的成功验证，他将获得整个密码，但他有被注意到的风险。

此时，银行需要权衡威胁#1 的风险和损害与威胁#3 的风险和损害，并考虑减轻威胁#3 的替代方法。认证方式有很多种，这里不再赘述；我将专注于威胁 #1。

如果威胁 #1 导致攻击，则攻击者拥有大量散列或非散列密码。请记住，散列只会对足够强的密码产生影响。无论如何，攻击者不太可能攻击所有账户，因为一段时间后，银行的欺诈模式检测会检测到他（可能不是 100% 准确，但足以减慢他的速度）。因此，他满足于专注于密码最容易破解的帐户；散列并没有让他减慢那么多。在这种情况下，散列提供的缓解效果不是很好。

如果您是一个使用强密码的用户，那么您会不希望受到攻击的影响，这是可以理解的——让行吟诗人首当其冲。银行有不同的看法：它不关心谁的账户被盗，只关心被盗账户的数量。如果此时你对银行不关心那些认真对待他们安全的极客感到愤怒——你有信用卡吗？只需拥有一个，任何人都可以通过快速说出一个 16 位数字来向您的帐户收取购买费用，因此您还有一段路要走。

密码哈希评估的另一部分是考虑替代缓解措施。银行不是托管在 5 美元 VPS 上的某种服务，它可以提供更好的安全性。例如，银行往往对其员工进行非常严格的控制，从而降低了内部违规的风险。对于外人来说，将密码存储在 HSM 中是一种很好但很笨拙的防御措施（尤其是备份很难）。加密密码并将加密密钥分开存储在多个智能卡上是另一种可能的缓解措施——它不能保护实时系统，但对备份有效。如果密钥和密码数据库足够独立，因此很难一起窃取，加密是对威胁 #1 的一种很好的缓解措施（它甚至适用于极弱的密码）。

考虑到所有因素，在这种情况下，密码散列并不是万能药。虽然这不是一个坏主意，但定性分析表明，需要可逆密码存储的替代方法可能会提供更好的安全性。需要对欺诈和可用性进行非常彻底的研究，才能定量评估使用密码中的随机字符进行身份验证是否值得放弃密码散列。

我的问题是这是否合理？

当然。

散列密码不是安全基础。对于您的数据库受到威胁的情况，这是一种非常具体的缓解措施。即使在这种情况下，它所做的只是给您一个时间缓冲，让您检测和分析入侵，与用户沟通并允许他们更改密码。

对于大多数系统来说，数据库泄漏仍然是一个灾难性的案例，但至少对于用户重复使用密码的其他系统来说，使用强散列不太可能受到灾难的伤害。

因此，如果您有其他措施可以降低数据库泄漏的可能性或破坏性，那么您当然可以证明加密但可恢复的密码是合理的。

这可能包括拆分敏感数据/加密密钥，以便必须破坏多个系统才能恢复密码；在其自己的服务器上进行密码检查，锁定访问权限，并针对未经授权的使用进行强大的审核，并检测可能表明前端服务器受到破坏的异常卷；不太可能在其他系统上重复使用的密码格式规则......等等。

这真的是一个更好的主意吗？

对此没有一个简单的答案。

目前，由于没有太多公认的数据可供分析，因此收益尚不易量化，而且收益肯定取决于组织安全配置文件的其他方面。（此外，在实施部分密码时很容易出错，这可能会破坏潜在的好处，并且通常部分密码与其他形式的凭证结合使用，因为它们本身很容易受到暴力破解。）

同样，组织的成本取决于用于阻止或减轻数据库泄漏案例的其他因素，以及它们与现有实践的契合程度。

总结：视情况而定。:-)

这可能是合理的，但不一定更好。

也就是说，想象一个服务代表您登录到另一个服务——例如：Mint.com。它登录到您的银行帐户并提取您的数据。

除非您的银行实施 OAuth 或其他委托服务，否则 Mint.com 必须加密存储您的银行凭据，以​​便它可以代表您行事。在 Twitter 实施 OAuth 之前，这就是旧版 Twitter 应用程序与您的 Twitter 帐户一起工作的方式。

这种将某人的密码存储在您的系统上的概念是一种安全气味，它导致了 OAuth 类型系统发生的信任委托。

此外，在真空中做出诸如“散列优于加密”之类的概括性陈述，考虑到安全性实际上是多么微妙，wrt 安全性并没有多大意义。与存储客户密码加密相比，使用无盐的密码散列（例如使用 MD5）的糟糕实现可能对您的系统安全性更不利，因此“更好”是主观的。

虽然密码可以使用加密的 HSM 存储，该 HSM 限制尝试验证以高度安全性呈现的数据，但我仍然认为与仅检查所呈现的信息泄漏相比，添加了什么安全性的说法是可疑的密码的子集。由于收益对我来说似乎是可疑的，我想说没有充分的理由以可恢复的格式存储密码以进行身份​​验证。也没有很好的方法来验证是否遵循了适当的 HSM 程序，因为我们过去曾看到大公司（甚至大银行）做出愚蠢的安全决策。如果 HSM 没有被正确使用，这是一个巨大的风险，因为数据库中的任何损害都会导致所有帐户凭据的泄露。

请注意，如果需要考虑弱散列，您也可以始终加密散列以获得两全其美的效果，因为可恢复的存储严重依赖于密钥保护。因此，即使您拥有“可靠”的密钥保护，散列仍然可以提供更高的安全性来防止单点故障。

当需要存储密码以供第三方服务使用时，应使用从用户密码派生的密钥对密码进行对称加密。通过这种方式，存储的密码在数据库泄露的情况下是不可恢复的，因为存储的密码只有在输入密码（只有用户拥有）时才能访问。