我正在构建一个安全的登录模块，并且我一直在阅读所有这些关于在散列之前对密码进行加盐等的指南。但是我觉得所有密码仍然是“可解散的”，可以同时访问散列和盐。
所以我开始考虑如果我只是将一段哈希存储在数据库中会怎样。在 PHP 中，当使用 SHA-256 进行散列时，我得到一个 64 个字符的字符串，如果我只是将其中的 50 个保存在数据库中并在登录时进行相同的 50char 比较，该怎么办？
暴力破解会产生一些额外的误报。但是他们仍然必须尝试很多很多密码，而真正的密码肯定是不可破解的。
我的想法是否遗漏了一些东西，或者这真的可行吗？
/ 安德烈亚斯
没有名副其实的哈希是可逆的。从 SHA-256 哈希的输出中丢弃 14 个字符将其减少为 SHA-228；这可能不是您的想法。如果您使用足够大的盐（64 位或更多）并且它是适当随机的，那么您将足够安全，如果您存储 64 个字符而不是 50 个字符，则更安全。
我觉得所有密码仍然是“可去除的”，可以访问散列和盐。
哈希不能被反转：这就是哈希的目的和本质。
攻击是，由于某些其他信息泄漏而知道散列，您通过计算输入变量的所有可能值的散列来蛮力解决问题，如果您受到打击，那么您猜测的值很有可能是最初用于创建哈希的那个。
Salt 减缓了这种攻击，因为它必须为每个密码单独完成，而不是一次预先计算，但是现代硬件可以如此快速地计算散列值，以至于它不再具有曾经的威慑价值。
您当然可以通过减少存储的哈希数据量来降低这种蛮力猜测正确的可能性：例如，如果您只保留 8 位哈希，那么攻击者就无法真正猜出原始密码，因为每 256 个密码中就有一个密码将匹配。但这样做的必要缺点是，您自己使用该散列进行身份验证被大大削弱，每 256 次随机猜测中就有 1 次进入。
使存储的哈希值更不易被唯一猜测的好处与使主身份验证接口更容易受到机会影响的成本成正比。离线可猜测哈希的情况仅在发生数据库泄露时发生，而不是像可猜测身份验证接口那样持续存在威胁，因此我们通常不太关心它。
在您的示例中，200 位哈希（50 个十六进制数字）仍然可能为所有常见密码字符串提供唯一值，因此几乎没有真正的好处。
最终，防止对泄露数据库进行离线猜测的问题是无法解决的，但我们目前最好的方法是让攻击者和真实身份验证服务器的哈希计算速度变慢。有关常见实现，请参见 bcrypt 和 PBKDF2。即便如此，这只能减缓大规模猜测离线攻击的时间，让您有时间在发现数据泄露后要求您的用户更改密码。