有几种可能性。

1. 他们可能以明文形式存储完整密码，并且仅向支持人员显示最后 4 个字符。

2. 他们可能会两次对密码进行哈希处理。一次对完整密码进行哈希处理，然后再对最后 4 个密码进行哈希处理。然后支持人员键入最后 4 个密码以查看它是否与哈希值匹配。这样做的问题是，由于最后 4 个字符位于单独的散列中，因此更容易暴力破解完整密码，从而减少了熵。

3. 他们可能正在对完整密码进行哈希处理，并以明文形式存储最后 4 个密码。显然，如果获得密码数据库访问权限的攻击者知道最后 4 位数字，这使得暴力破解密码变得更加容易。

4. 最后 4 个字符以某种可以发现的方式存储的其他内容，例如 Mike Scott 在下面提到的加密。如果能发现解锁这4个字符的秘密，这和明文一样糟糕。

所有的场景都很糟糕，大大降低了系统的安全性。不可能知道他们正在使用哪种方案，但他们每个人都表现出缺乏对安全漏洞的考虑。如果这是一个您关心您的帐户被破坏的网站，我建议您谨慎行事。

由于我们不在Bluehost的秘密中，所以总是很难回答这样的问题，所以我们只能猜测和假设。

但是，您描述的行为在不存储任何明文密码的情况下仍然是可能的：

• 当您创建新帐户或重置密码时，密码会发送到服务器，很可能以受 TLS 保护的明文形式发送，
• 然后，服务器将为相同的密码生成两个不同的哈希值：
  • 第一个哈希获取您的完整密码并用于通常的身份验证，
  • 第二个哈希只取密码的最后四个字符，
• 当您联系他们的支持团队时，您告诉他们您的最后四个字符，他们在他们的软件上键入它们，然后他们的软件将在内部计算一个哈希值，检查它并将结果显示给支持技术人员。

BlueHost 建议合理的强密码规则，因此他们可能至少雇用一个知道他在做什么的人。

假设这样，BlueHost 可能正在使用Shamir's Secret Sharing的实现或该主题的变体。Shamir 在理论上是安全的，所以我不会立即得出结论（就像其他答案一样），任何这样做的方案本质上都不安全。

另一方面，实施 Shamir's 并非易事，因此任何其他答案都同样适用。由于安全最终是关于信任，如果您对此方案感到不安全，我建议您寻找其他提供商！

我不能确切地告诉你他们是如何存储密码的。但是从您对其流程的描述中，我们可以看出密码必须以不安全的方式存储。

我假设当他们询问最后四个字符时，他们实际上能够验证您告诉他们的内容的正确性（换句话说，他们不仅仅是在虚张声势）。

这意味着他们拥有数据，可以让他们在短时间内验证您告诉他们的字符。相同的数据可用于暴力攻击以破解密码的最后四个字符。四个字符肯定太短，无法阻止坚定的攻击者。

一旦攻击者拥有最后四个字符，就可以对较早的字符进行另一次攻击。对于这种蛮力攻击，密码的最后四个字符没有添加任何安全性，因此充其量您拥有的安全性与密码的等效安全性比实际短四个字符。

可以通过选择一个安全密码然后附加四个完全独立于最初选择的密码而选择的额外字符来解决该漏洞。如果他们只能验证最后四个字符而不是任意长度的后缀，这将是安全的。

如果他们实际上能够验证任意长度的后缀，而不仅仅是四个字符的后缀，那么密码存储会更弱。这与将其存储为纯文本一样不安全，在这种情况下，您无法通过选择更强的密码来解决它。