有可能该服务不仅在创建完整密码时计算了完整密码的哈希值，而且还单独对第 3 和第 7 个字符（或可能每个字符）进行了哈希处理。这样，他们在技术上不会以明文形式存储字符或完整密码。然而，这将是一个可怕的想法。单个字符的散列本质上并不比明文更好，因为每个盐可能只有 62 个可能的单字符散列（如果使用盐）。

无论哪种方式，如果服务能够识别部分密码而不是仅识别完整密码，那么这就是坏消息。

如果可以按字符验证密码，则会显着降低密码的有效强度。而不是每个角色都呈指数级增长，它只会越来越强。

例如，假设我有一个长度为“ABCD”的四个字符的密码。如果我必须知道整个密码才能正确设置，则可能的排列（例如，为了参数只允许使用大写、小写和数字）是 62^4 或 1480 万种可能的组合。另一方面，如果我可以自己确定每个字符是否成功，我可以在 62 * 4 组合中找到密码，或者使用蛮力进行 248 次操作。

因此，尽管以这种方式散列密码可能会也可能不会，但这样做会有效地消除这样做的任何安全性。

任何要求用户提供密码详细信息的身份验证都表明系统可以使用明文密码。这意味着它们没有经过哈希处理，但仍可能通过其他方式进行加密和保护。

没有任何技术可以针对整个散列密码验证散列密码的子集。这实际上是哈希函数的目标之一，因为它可以防止逐字符猜测密码。

正如之前的答案已经说明的那样，没有已知的技术可以对密码进行部分散列并验证字符串。单向散列函数的性质使得无法验证密码是否与另一个密码相似，只能验证密码是否相同。因此，这意味着银行已经使用双向加密，通过对子字符串进行哈希处理，或者（恐怖！）以明文形式存储了密码。

这种技术实际上有许多优点和缺点，与目前认为这种技术没有补救因素的观点相反。

银行密码的泄露可以通过两种方式发生，通过入侵银行服务器导致哈希泄漏，或通过用户端的密码泄露（键盘记录器、木马、简单的肩部冲浪、SSH 上的 MITM 攻击）等。

以允许检索子字符串的方式存储密码允许已获得银行数据库访问权限的黑客轻松获得明文密码，即使它们非常强大。如果银行使用双向加密，获得加密数据库访问权限的黑客几乎肯定能够获得密钥。如果他们对选择的子字符串进行散列，则会导致类似于NTLM 弱散列的情况，这将使检索明文密码变得容易。即使使用了盐，3-5 个字符的非常小的散列空间（假设使用了散列）会使反转尝试变得微不足道。

然而，这必须与替代风险相平衡。一个潜在的银行黑客只能访问受害者的计算机（可能还有他们的 2 因素身份验证令牌）将无法访问受害者的银行帐户，因为需要与密码不同的字符子集。

由于后一种银行账户安全受损的可能性更大，因此银行实施这种散列系统在一定程度上是有意义的。