在 MySQL 上存储 BCrypt 哈希的正确方法答案

【问题标题】：Proper way to store BCrypt Hashes on MySQL在 MySQL 上存储 BCrypt 哈希的正确方法
【发布时间】：2017-08-20 09:36:19
【问题描述】：

寻找在 MySQL 中存储 BCrypt 哈希的正确方法我找到了this question，这只会让我更加困惑。

公认的答案指出我们应该使用：

CHAR(60) BINARY or BINARY(60)

但是 cmets 上的其他人认为我们应该使用：

CHAR(60) CHARACTER SET latin1 COLLATE latin1_bin

甚至：

COLLATE latin1_general_cs

我不是数据库专家，所以谁能解释一下所有这些选项之间的区别以及哪一个更适合存储 BCrypt 哈希？

【问题讨论】：

据我所知，加密哈希是比特流（即二进制），但通常表示为纯文本。你需要存储什么格式？
您的问题非常接近“有人可以帮我阅读有关 MySQL 数据类型的文档并做一个执行摘要吗？”
@ÁlvaroGonzález 是的，哈希是比特流，是的，它被编码为纯文本，但是所有这些存储选项都会导致数据库上出现不同类型的行为。
@Tomalak 这真的不是我的意图，我已经阅读了 BINARY 和 CHAR 的文档以及 _bin 类型的排序规则差异，但是，我看不到彼此的好处以及它们的比较方式，他们一路上的警告和惊喜，所以我的意图实际上是问一个比我更有经验的人来比较这两个选项。
@mFeinstein 你应该提供赏金。我认为这是一个重要的问题

【解决方案1】：

我的回答是“什么是正确的”，而不是“什么会起作用”。

不要使用latin1。当然，它可能会起作用，但是声称加密的字符串不是文本是很难看的。

CHAR... 同上。

如果是固定长度，只需说BINARY(...)，如果长度可以变化，就说VARBINARY(...)。

但是，有一个问题...您使用的是谁的 BCrypt？它是否返回二进制数据？还是十六进制字符串？或者甚至是 Base64？

我上面的答案假设它返回二进制数据。

如果它返回 60 个十六进制数字，则将 UNHEX(60_hex_digits) 存储到 BINARY(30) 中，以便将其压缩得更小。

如果它是 Base64，那么 CHARACTER SET ascii COLLATE ascii_bin 将是“正确的”。（带有区分大小写排序规则的 latin1 也可以。）

如果它是二进制的，那么BINARY(60) 是“正确”的做法。

您提供的链接看起来像 Base64，但是是吗？最多 60 个字符吗？然后我会使用

VARCHAR(60) CHARACTER SET ascii COLLATE ascii_bin

并显式声明列的字符集/排序规则，从而覆盖数据库和/或表的“默认值”。

所有 Base64 字符（和 $）都是 ascii；不需要更复杂的字符集。与 ..._bin 进行整理意味着“精确比较字节”；更具体地说“不要折叠大小写”。由于 Base64 依赖于区分大小写字母，因此您不希望大小写折叠。

【讨论】：

我认为我们不能将 bcrypt 视为纯 base64 字符串，因为它总是有前缀“$2a$”或“$2b$”或“$2y$”，这可能将来对协议的任何更新和成本参数（大约 10 美元）都会有所不同。目前，哈希是 60 个字符长，盐和哈希是 base64，但前缀不是。
@mFeinstein - 没关系。我的建议仍然有效（在我修正了一个错字之后！）
您能否详细说明使用 ascii_bin 排序规则的优点？我不是数据库专家，所以我不了解提供的所有好处和保护。
我加了一段。