我已经阅读了有关 php 登录脚本的各种主题，因此我不打算回顾这些讨论，但我想知道在密码哈希中使用真盐和假盐。
我在考虑 ID#/ID/密码登录提示，而不是 ID/密码登录提示。我的用户都有 ID，与他们在职业中经常使用的我的公司无关。如果他们输入匹配的真实 ID# 和登录 ID，那么他们会得到真正的盐。所有不匹配的条目都会导致密码的假盐。虽然这些 ID#s 可能在 Internet 上可以获得，但您必须知道用户的名称，这会使所有随机攻击都失败。使攻击起作用的唯一方法是首先发现用户名，然后攻击我的系统。用户身份并不为人所知。
这是一种可行的方法吗？如果我在一定次数的尝试后还锁定了一个 ID，并在如此多的 GLOBAL 尝试失败后延迟登录尝试，可能会出现什么问题。但是，我不会对任何涉及假盐的尝试进行锁定或限制。我只打算在他们获得真正的盐时实施这些故障保险。但是，如果他们获得现有的 ID#，我可能会考虑限制。
想法或建议？这会是禁止 IP、询问个人问题、验证码等的安全替代方案吗？
我将把它写成一个答案，因为您似乎对盐是什么以及它是如何工作的感到困惑。
盐应该是为每个用户生成的随机字符串。在加密他们的密码并将其存储在数据库中之前，您添加盐并将其也存储起来，从而更改加密值。salt确保如果有人访问您的数据库并且实际上是您的用户的加密密码，他们不能使用彩虹表快速查找他们未加密的密码。
彩虹表是值及其加密对应项的列表，通过预先生成值列表，攻击者不需要暴力破解加密密码，并且可以在O(1)查找中“解密”它。因为你为每个用户随机生成一个盐，你使他们的表一文不值。
它不会阻止他们暴力破解密码，也不能替代强加密。
没有什么。它不存在，没有什么好的目的。
首先，用户不应该看到或知道他们的盐值，它存储在您的数据库中并由您的身份验证逻辑使用。在测试密码的有效性时，没有理由不使用他们的实际盐。如果密码错误，无论如何都将无法通过身份验证。
其次，如果攻击者试图使用不存在的用户名登录，那太棒了，他们将永远无法访问帐户，并且不需要采取进一步措施，除非他们因请求而使您的服务器超载，在这种情况下您需要想办法暂时阻止他们。
适当的答案将取决于您的公司能够承受的安全级别或不安全级别。例如，系统会被审计吗？系统中的用户是如何创建的？用户是否会从非私人计算机访问此资源？
虽然，我可以看到实施这样一个系统的理由，但我不推荐它。我认为其他人甚至会声称这完全荒谬。这样做的原因是，如果您有任何面向 Web 的应用程序，系统的安全性极有可能会受到损害。
此外，完全阻止 IP 地址会导致糟糕的用户体验。我建议实施反向图灵测试（如 Capthcha 或 Mathcha）。
但最终，我对尝试摆脱密码身份验证的想法表示赞赏。作为用户，我讨厌密码。我的雇主（我假设大多数情况下）关于密码的安全政策本身就是可笑的。
编辑：我刚刚重新阅读了您的评论说this would make all random attacks fail。我想补充一点，这个假设对我来说似乎没有很好的根据。猜测用户名比您想象的要容易得多。特别是如果这是他们的真名。