也许我不明白，但如果我是攻击者，我会执行以下操作：

我会偷两张桌子。然后我会选择一个我感兴趣的用户（例如管理员）并开始使用他的 salt 对密码进行哈希处理，并查看是否可以在哈希表中找到生成的哈希值。

那么有什么区别呢？（除了我必须查找计算的哈希是否存在而不是仅仅比较（数据库服务器擅长此类任务）

PS：作者还认为，表的大小可能会使攻击者更难窃取它。那是个很好的观点。（除非他没有窃取它，而是在站点的数据库服务器上运行查找查询）

这是一个有趣的想法，应该成为更多（学术）研究的主题。

PPS：作者在这里提出了一种修复隐藏后门问题的方法。第一印象这似乎解决了它。

我认为它很愚蠢。验证您已经可以使用 bcrypt 控制的成本会更高。此外，使用弱密码的众多用户中的一个很可能会与管理员的 salt+strongpass 发生冲突。当有 100 万用户时，密码匹配的机会将增加 100 万。控制性能也更难。如果您想重置用户密码会发生什么？您将拥有孤儿密码，如果密码匹配，也会对其进行检查。

还有一些逻辑问题，例如：如果您想对数据库进行分片，以便来自某些大陆的用户拥有专用于他们的服务器，该怎么办？有太多的问题。所有这些都是为了防止有人在窃取哈希时猜到您的密码？如果哈希被盗，您还有其他问题，例如其他什么被盗。只需在较慢的时间内使用具有更多通行证的 bcrypt，这不会导致冲突和其他提到的缺点。

愚蠢的...

-edit- 我重新考虑了性能差异。在考虑之后，可以对哈希进行排序和组织，因此您实际上不需要查看人们可能想象的那么多。不同之处在于检查密码的 CPU+磁盘/内存的 CPU 性能。最大的区别是黑客需要获取多少数据。但请记住，负担也在你身上。我宁愿强制更多的 CPU 时间（这可以使用 bcrypt）然后我需要多少磁盘空间。

入侵者传输所有数据可能更明显或需要更长的时间，但如果 CPU 时间足够长以至于需要数周时间来解码 6 个字母的密码（请记住，您可以强制用户使用更长的密码）并且您注意到入侵一周（更不用说一天），那么您可以锁定所有旧密码。以安全的名义让你的数据变胖是不值得的。（这有点像通过默默无闻的安全，除了它只是胖而不是秘密）

我发布了一篇后续文章，更详细地解释了我的设计目标是什么，以及为什么碰撞在这里不是问题：http ://www.opine.me/all-your-hashes-arent-belong-to-我们/

这种方法将哈希与特定用户分离，并使用随机数据模糊您的哈希表。这不是作为 scrypt 的替代品，而是试图增加跨新轴（存储和带宽）的攻击成本，这将有助于阻止和增加对窃取哈希值的尝试的检测。

另一个好处是攻击者不能再针对特定用户，除非首先设法窃取您可以直接设置大小的数据库的大部分。

好的，因此您正在尝试防止可以访问您的数据库的攻击者从中受益。

如果说我是攻击者，我会循环浏览您的用户表，并为所有用户的标准密码创建新的哈希值。当您使用盐时，这意味着哈希表会随着用户数量的增加而增长，但由于您拥有如此臃肿的哈希表，您不太可能注意到。

简而言之，我不确定您是否获得了任何额外的保护，但是您正在失去性能，随着解决方案的扩展或用户的来去，性能会变得更糟。