密码散列: Keccak与否

Question

选择了SHA-3哈希算法竞赛的获胜者。胜利者算法是Keccak。

我用的是河豚，我真的很喜欢它，但是Keccak据说更好。用它在我的网站上存储用户的密码值得吗？

如果是，是否有用于web编程的用于PHP、Python、Ruby或任何其他语言的Keccak实现？

我希望这个问题对其他人也有帮助。谢谢!

Answer 1

I use Blowfish and really like it, but Keccak is said to be better.

“更好”是这样一个相对的词。在什么方面更好？安全性、性能、可扩展性、可移植性.？

如果您只想获得更大的“安全性”(仅用于散列用户密码)，那么Keccak可能是一个而不是的好选项。河豚会给你更好的“安全性”，因为它将需要更长的时间来蛮力-强制哈希，如果散列被发现。

尽管如此，如果您想要在嵌入式体系结构上运行什么，或者如果您想要更好的可移植性，那么Keccak是一个不错的选择。以下是github上的PHP实现和这是另一个 --您还可以通过下载Keccak源进行自己的语言扩展。

但是，老实说，最好还是坚持你所知道的。如果黑客可以很容易地获得您目前正在使用的河豚散列，那么问题不在于散列算法，而在于对数据库的访问。还请注意，PHP扩展必须使用此方法安装在所有服务器上，如果您使用共享主机，这可能是可能的，也可能是不可能的。

在现实中，你可能应该坚持你所拥有的。它很可能是足够安全的，一旦将Keccak实现移植到标准PHP核心，您就可以移动(如果需要的话)。只有我的两分钱。

Answer 2

简短答覆：

不，而且可能永远也不会。对于密码哈希，BCrypt & PBKDF2-HMAC-xxx是比任何简单的SHA-1/2/3算法更好的选择。在SHA-1/2实际发布了可行的预图像攻击之前，SHA-3实际上是最糟糕的选择，特别是因为它速度快、缓存占用少。

较长的答覆：

不同密码哈希算法的相对安全性的一个主要因素是:与您相比，专用攻击者能够以多快的速度散列密码？也就是说，他们的软件/硬件组合(为密码哈希的目的而购买)比服务器上的软件(软件的现成C实现，为您的应用程序的需要购买的硬件)要快得多。

SHA-3的主要标准之一是，应该在嵌入式体系结构上高效运行，嵌入式体系结构的典型特点是少量的片上缓存、寄存器等。但这也描述了现代GPU:寄存器/累加器较少，片上缓存较小；但另一方面，它们的硅被优化以在大量数据上并行执行相同的任务。这对于攻击者的蛮力尝试来说是完美的:因为永远花费在硅上的攻击者通过购买另一个GPU而获得更多的SHA3散列，而不是通过购买更好的CPU。

由于这个特定的原因，BCrypt被设计成对内存中的表执行更多的读/写操作，这个表目前比大多数GPU的缓存都要大。这意味着当前基于GPU的BCrypt实现甚至无法与它们的CPU相媲美。因此，只要选择BCrypt，就会降低攻击者花费的每一美元的优势，迫使他购买与您相同的CPU。

这就是为什么原始速度是密码哈希的敌人。您希望选择其软件/硬件组合速度最快的算法，与您将要使用的普通软件/硬件相比，该算法每美元提供的优势最小。现在，这是BCrypt，或者PBKDF2-HMAC-xxx的稍微小一些的选择。由于GPU可能只会更好地执行SHA3，我怀疑它是否会是正确的选择。我在SHA3上没有数字，但是“哪个更安全”不是一个模糊的相对术语--上面的规则可以用来精确地量化它。

Answer 3

这是一个老问题，但听起来每个人又被密码术语搞糊涂了。让我们把一些事情弄清楚。

• Keccak是一个密码散列函数。
• Blowfish是块密码(它有64位块大小，不应该再用于加密)。
• Bcrypt是一个密码哈希函数，它与单纯的密码散列函数有不同的用例。Bcrypt是以Blowfish为基础的，但它不是河豚。

我不仅仅是学究，这些区别很重要，因为Keccak不是和bcrypt竞争，而是和SHA-256竞争。

这里有一个简单的在PHP中安全地存储密码方法

1. 使用password_hash()、password_verify()和password_needs_rehash()

就这样。您甚至不需要关心这些函数做什么，您只需要使用它们(除非您使用的是like之类的东西)。

目前，这个接口提供了bcrypt。Bcrypt大部分都很好，除了几颗脚踏子弹要注意：

1. 它截断72个字符后的密码，降低了长密码的安全性，每个字符的密钥空间熵较低。
2. 如果您试图通过预散列来避免前面的脚弹，请注意不要将原始二进制传递给bcrypt，因为它也会在NUL字符之后被截断。

如果您担心这些问题，那么在锁定中存在一个临时的权宜之计。

在PHP7.2中，很可能通过这个接口使用Argon2i (假设RFC通过)。

几年后(假设没有重大版本问题的话，大约可以使用PHP7.5)，我们可能会看到PASSWORD_ARGON2I成为PASSWORD_DEFAULT的新值，但可能不会。我们有几年的时间让密码学研究人员对它有信心。