#1 楼
有多种可能性。他们可以用明文形式存储完整密码，并且只能
向支持人员显示最后4个字符。
它们可能是哈希密码两次。散列完整密码后，
再输入最后一个4。然后支持人员键入
后4个，以查看它是否与散列值匹配。
的问题在于，由于后4个字符位于单独的哈希中，因此可以更轻松地强制使用完整密码。
它们可能会对完整密码进行哈希处理，并存储
后四个纯文本。显然，如果可以访问密码数据库的攻击者知道后4位数字，那么使用蛮行密码更容易。
以其他方式存储后4个字符的其他方式
可以发现，例如Mike Scott在下面提到的加密。如果能够发现解锁这4个字符的秘密，这和纯文本一样糟糕。不可能知道他们正在使用哪种方案，但是每个方案都缺乏对安全漏洞的考虑。如果这是您关心帐户遭到破坏的网站，我建议您谨慎。
评论
至少还有一个选择。他们可能会散列完整的密码，并使用对称加密来保存最后四个字符，因此他们的软件可以为支持人员解密它们。仍然很糟糕，但还不算很糟。
–麦克·斯科特（Mike Scott）
2015年9月17日下午15:19
而且，大多数好的网站都会说出这样的话：“这里没有人会要求您输入密码。”当然，意思就是最后四位数字都没有...
–装甲危机
2015年9月17日下午16:34
出于所有目的和目的，存储后4个散列也等同于存储纯文本。使用现代GPU，您可以立即使用该功能。
– Mikeikeazo
2015年9月17日在18:06
@IsmaelMiguel如果您要对四个字符进行哈希处理，那么加盐将无法为您节省。假设这些字符是从90个左右的一组字符中选择的，那么只有六千五百万种可能性，并且可以很快对其进行暴力破解（除非他们使用bcrypt之类的东西，且其工作因数足够高以减慢操作速度）用户注意到滞后的点）。
–麦克·斯科特（Mike Scott）
2015年9月17日19:13在
如果最后四个字符是使用具有大量冲突的哈希值存储的，该方法将用于简单的一次尝试验证，该怎么办？如果此哈希值被强行使用，它将生成许多错误结果，这将无助于获得完整的密码。
–古斯塔沃·罗德里格斯（Gustavo Rodrigues）
2015年9月17日19:18在
#2 楼
由于我们不是Bluehost的秘密，所以总是很难回答这样的问题，因此我们只能猜测并做出假设。但是，您描述的行为仍然可以实现，而无需存储任何明文形式的密码：
创建新帐户或重设密码时，密码将发送到服务器，最有可能是受TLS保护的明文形式，
然后服务器将生成两个不同的哈希表示相同的密码：
第一个哈希使用您的完整密码并用于常规身份验证，
第二个哈希仅使用您密码的最后四个字符，
当您与他们的支持团队联系时，您告诉他们您的最后四个字符，他们在他们的软件上键入它们，然后他们的软件将在内部计算哈希值，对其进行检查并将结果显示给支持技术人员。
评论
他们为什么会为此使用您的一部分密码？这就是安全PIN的用途。
–章鱼
2015年9月18日于22:05
@章鱼：如上所述，我们不是Bluehost的秘密，所以我当然不能回答“为什么”，只能猜测“如何”。而且，甚至大多数Bluehost的员工也可能无法真诚地回答“为什么”这样设计系统：在某个时候，几个人，经理和项目负责人在一个房间里开会，认为这是最好的选择，只有他们知道在这次会议上讨论的确切利弊。
–WhiteWinterWolf
2015年9月19日在9:10
#3 楼
BlueHost建议使用强密码的合理规则，因此他们可能会雇用至少一个知道他在做什么的人。假设BlueHost可能在使用Shamir的Secret Sharing或该主题的变体。 Shamir的理论上是安全的，因此我不会立即得出结论（如其他答案所言），任何这样做的方案本质上都不太安全。
另一方面，实现Shamir并非易事，因此其他任何答案都可以同样适用。由于安全最终关系到信任，因此，如果您对这种方案感到不安全，建议您找其他提供商！
评论
或者他们能够复制其他人的合理规则列表。不幸的是在这里。显然是从旧的Microsoft页面复制了密码。他们甚至没有对其进行调整以使其适合自己的网络，例如“ Password Checker是该网站上的非记录功能”一句话（链接到Microsoft的Password Checker），或者讨论了不同Windows版本上的空白密码（超出bluehost的范围）。
–Ángel
2015年9月19日在20:15
有了这些提示，他们甚至都不承认此内容来自2006年Microsoft的一篇文章（难道很难说“ Microsoft推荐以下技巧来提供安全建议”？），我非常怀疑它们得到了获得版权所有者（可能是Microsoft）的复制许可。但是，比侵犯版权更为重要（对于一家公司而言，这足够麻烦了），我认为我们可以推翻毕晓普的结论，并得出这样的结论，即他们没有雇用一个了解这一点的人（或者至少他们没有聘请知道这一点的人） '）。
–Ángel
2015年9月19日20:21在
这使我更加警惕这家公司的安全性。如果他们因不重要的密码建议而错了什么事，我怎么能确保他们为大决策做了正确的事情？特别是在得知他们已经“使用最后4个密码字符”进行电话验证的可疑做法之后……
–Ángel
2015年9月19日在20:25
@Angel Nice研究并同意：由于没有任何其他有关安全意识的证据，我怀疑它们的动机和实现。
–主教
2015年9月21日13:21在
我不明白为什么这样做会更安全。唯一更安全的方法是，您可以为服务台人员提供一个“零件”，该零件必须经过社交工程设计。除此之外，您现在只需将4个字符与其他已知部分一起暴力破解，直到获得与之匹配的秘密为止。即使在需要k + 2个部分的情况下，系统中有k个部分，k个服务台人员和1个仅由客户知道的秘密，您最终最多还是可以拥有k个部分，您可以将其与另一个秘密进行比较找出哪一部分不起作用，因此必须是客户的一部分。
– Sumurai8
2015年9月21日19:04
#4 楼
我无法确切告诉您他们如何存储密码。但是从您对他们的过程的描述中，我们可以证明密码必须以不安全的方式存储。我假设当他们要求输入最后四个字符时，他们实际上将能够验证密码。您告诉他们的话的正确性（换句话说，他们不仅仅是在虚张声势）。
这意味着他们拥有的数据将使他们能够在短时间内验证您告诉他们的字符。可以在蛮力攻击中使用相同的数据来破坏密码的最后四个字符。当然，四个字符太短了，无法阻止坚定的攻击者。
一旦攻击者拥有最后四个字符，就可以在较早的角色上发起另一次攻击。对于这种蛮力攻击，密码的后四个字符没有任何安全性，因此充其量，您可以得到比实际短四个字符的等效密码。
可能可以解决通过选择一个安全密码，然后附加四个完全独立于最初选择的密码的其他字符来发现漏洞。如果他们只能验证后四个字符而不是任意长度的后缀，那么这将是安全的。
如果他们实际上能够验证任意长度的后缀而不是仅验证四个字符的后缀，则将是安全的。 ，密码存储空间甚至会更弱。这和将其存储为纯文本一样不安全，在这种情况下，您无法通过选择更强的密码来解决它。
评论
的确，如果您可以验证任意长度的后缀，那就结束了。只需256次猜测（或更少）即可验证最后一个字节，然后再进行256次猜测即可验证最后两个字节（知道最后一个字节），依此类推，直到您知道256 * n次猜测中的完整密码为止。正如您所说，就存储散列的脱机攻击而言，也可能是纯文本。
–史蒂夫·杰索普（Steve Jessop）
2015年9月18日在0:44
#5 楼
如您所知，在存储密码之前应先对哈希进行哈希处理，因此您必须问自己是否天气，出于口头授权的目的，它们存储的是最后4个字符，然后在存储之前对密码进行哈希处理，或者他们只是在存储密码明文。我猜是后者。
#6 楼
我认为这不可能，只是可能。每当OP需要支持时，他们都会要求输入他密码的后4位数字。他们对其加盐并进行哈希处理，并将盐和哈希及足够的信息存储在特殊的支持表中以重建支持。
然后，当OP登录（使用完整密码）时，他们可以查看支持表并计算散列然后他们提交经过验证的“支持”并否定伪造的“支持”。
这当然假定
支持是可以提交或废除的东西稍后，
询问最后4位的过程不会泄漏信息（有人要求您获得最后4位不符合资格，因为我们无法可靠地擦除他们的记忆）。
我无法想象这种情况将具有商业意义。但是，如果这样做的话，我想我应该为用户提供一个特殊的4位“支持”密码。
评论
并且，如果存储的尚未验证的“支持”可以与散列的完整密码一起被盗，它们仍然是解密者的宝贵帮助。
– Ben Voigt
2015年9月18日在22:27
@BenVoigt是的，强行强制使用最后4位数字是可行的，因此将其加盐不会增加太多价值。或者，如果攻击者可以观察到哪些支持已被落实或拒绝，并且攻击者可以在不触发中断的情况下自动执行支持请求，则观察者可能可以在线暴力破解最后4个支持。
–emory
2015年9月21日在10:06
如果用户发出一堆支持请求，然后忘记了密码，则将提交或拒绝支持请求。如果已提交，则攻击者可以提出一堆支持请求，然后假装为用户“忘记密码”。如果拒绝，则攻击者可以拒绝真实用户的支持请求。
–emory
2015年9月21日在10:09
#7 楼
他们可以看到完整的密码吗？是的，他们绝对有可能猜出密码（如果最后4位数字是日期或单词的一部分。如果密码被完全散列，那么知道4位数字就足以进行蛮力攻击甚至是尝试启发式在散列函数上查看4位数字如何传播回去，从而大大减少了可能的密码范围。请输入以下密码：
*********ange
或这个问题：
****1994
他们也有可能成为黑客并利用客户支持API（如果有）来访问用户信息，通过了解，该任务甚至变得更加容易4位数字。
他们不应该这样做，在任何情况下都绝不能给陌生人一部分密码（尤其是，如果他被解雇了，他可能会试图伤害用户，并且在那里有很多历史示例）（如果它是客户支持的一部分）。
客户支持应该没有办法访问原始密码，并且应该通过即席API进行操作以防止发生不良后果。 ings（仍然支持人员不能访问完整数据）。
此外，如果客户支持人员要求输入4位密码，则您无法通过电子邮件向用户发送警告，例如“从不输入密码，因为我们不要求这样做”，因为您实际上是在要求并培训用户提供个人详细信息，可能会帮助他们被网络钓鱼电子邮件捕获。
如果他们真的想检查用户的权限，则应该使用诸如SMS代码，秘密问题或只是电子邮件发送的密钥之类的东西。
我仍然认为，发送电子邮件或SMS比花1-2分钟的时间做同样的事情要便宜得多（除非她/他确实是薪水过低的人）。
如果某项服务确实需要检查某人的重要身份，那么我可能会使用网络摄像头流，以便操作员可以看到用户的脸部，然后要求其执行特定操作（例如在纸上写一个字然后再显示给他）为了防止他人使用录制的视频）。
由于隐私，用户当然不会喜欢它^^
评论
您的答案没有回答问题。附带说明：我不相信这里的任何人都在倡导这样的系统是最佳实践，甚至没有问题，但这并不是这里的主题。
– Selenog
2015年9月23日10:58在
现在正在回答^^，我忘了写那部分，因为我正忙于写答案的“其他部分”。 @Selenog
–CoffeDeveloper
2015年9月23日在11:04
@Selenog，此时应该撤销否决票吗？
–CoffeDeveloper
2015年9月23日在11:13
#8 楼
正如其他人所说，此提供程序可以采用多种方法来保护密码的“后四位数字”。但是，无论何时广播甚至一部分密码，您都在敞开心to让自己的帐户遭到破坏。似乎没有人提到的一件事是，您输入到聊天日志中的密码的后4位可能未加密。显然，聊天记录需要易于访问。即使遵循基本的密码复杂性规则，您也仅将密码的有效长度减少了4个字符。现在想象一下，如果您在其他地方使用的密码安全性较轻（不幸的是，很多人都这样做）。TL：DR
这是一个荒谬的做法，我会避免使用不惜一切代价从他们那里
评论
我会说这是明显的白痴。看不见的白痴会带来更多问题（例如，允许软件开发公司聘用他们开发客户关系系统的人员，并在加密之前先查看已加密的密码）。
–peterh-恢复莫妮卡
18/12/20在23:24
#9 楼
他们可能会存储您整个密码的哈希值，再加上最后四个字符的哈希值，然后是12个随机生成的字符。如果它们生成随机字符的方式与散列过程一样安全，那么这应与自己存储密码一样安全。评论
那行不通。您将如何自己验证最后四个字符？
–卡巴斯德
15年9月17日在17:48
这与用12个字符的salt字符对4个字符的尾部口令加盐不一样吗？问题在于4个字符太小，以至于盐不能阻止强力搜索。加盐仍然不能阻止暴力搜索。
–史蒂夫·杰索普（Steve Jessop）
2015年9月18日，0：42
任意数量的附加字符确实增加了这个答案的荒谬性。
– underscore_d
2015年9月18日23:00
评论
所有情况都是可能的。下次您需要支持时，请给他们其他四位数。正如@Begueradj所说，所有情况都是可能的。这包括安全剧院。
@immibis，您的建议是，任何人都可以通过简单地呼叫并提供错误的信息来锁定另一个人的帐户？
如果我按照您的描述进行了体验，那么我将停止使用Bluehost。
作为Bluehost的前雇员，我可以告诉您，他们不知道整个密码。代理仅在一个框中键入密码的后四位，然后系统将根据文件中的密码对其进行检查。如果匹配，它将变为绿色并被记录，如果不匹配，则将变为红色并标记该日志。即使他们确实知道密码，该员工所做的所有操作都会记录在该帐户上，然后可以查看是否假定有任何事情发生。至于密码和加密的存储，打败了我，但我从未听说过任何