存储散列密码字节而不是字符答案

【问题标题】：Storing hashed password bytes instead of chars存储散列密码字节而不是字符
【发布时间】：2019-02-11 19:31:48
【问题描述】：

我最近的发展使我进入了密码存储安全、散列函数的世界......

我决定将我的哈希函数的结果字节数组（在 BINARY 类型列中）以及 salt 存储在数据库中，因为存储十六进制字符串会占用更多空间，我猜。

这种做法有什么缺点吗？尤其是在安全方面。

+----+---------+--------------+--------------+---------------+------------+
| id | login   | password     | salt         | name          | lname      |
+----+---------+--------------+--------------+---------------+------------+
|  1 | myadmin | 0x8B624d85B1 | 0x248f1706f0 | Administrador | do Sistema |
+----+---------+--------------+--------------+---------------+------------+

【问题讨论】：

标签： security hash binary passwords password-hash

【解决方案1】：

从安全角度来看，我看不出将哈希和盐存储为二进制而不是字符串的任何缺点。无论如何，最终所有数据都是二进制的。

我会更关心您使用的是什么散列算法。我没有看到您在任何地方存储难度系数，所以我假设您没有使用 BCrypt？如果没有，您可能需要考虑使用它，因为它似乎是目前密码哈希的黄金标准。

【讨论】：

Argon2，该表只是说明性的。我听说 Argon2 太新了，因此不太安全，但我正在尝试。
+1 用于使用 Argon2（哪个变体？2d？2id？。它是最近的，但作为密码哈希竞赛的一部分，它也受到了相当多的审查。
2d，我在一个服务器上运行一大堆应用程序，所以“应该”几乎不可能侧面攻击我的服务器
@LucasNoetzold - 将来升级到新算法可能会变得更加困难。字符串格式通常包括所有必要的信息，如盐、成本因子和算法签名，您也必须存储这些信息。内置函数大多是向后兼容的，这意味着即使它们使用旧算法计算，它们也可以验证密码。