如何在MariaDB v10.5中安全存储API令牌？

两种方案没有绝对的“更合适”，完全取决于你的业务需求——核心差异就是是否允许用户后续查看、找回API令牌，具体分析如下：

方案1：哈希存储（优先推荐，除非有刚需） #

这是行业内处理敏感凭证的标准做法，安全性拉满：

• 不可逆性是核心优势：用bcrypt、Argon2这类慢哈希算法处理令牌后，数据库里只存哈希值。就算数据库被攻击者拖库，他们也没法反向还原出原始令牌，能把数据泄露的危害降到最低。
• 流程要点：生成令牌时，把原始令牌返回给用户让他们自己备份（必须明确提示用户——一旦关闭页面，系统再也拿不到这个令牌了）；验证时，把用户传来的令牌做相同哈希运算，和库中存储的哈希值比对即可。
• MariaDB 10.5的支持：虽然数据库本身有PASSWORD()、ENCRYPT()这类函数，但更推荐在应用层做哈希运算——毕竟应用层能灵活选用最新的强哈希算法，比依赖数据库内置函数更可控。

方案2：可逆加密存储（仅用于必须让用户查看令牌的场景） #

只有当你的业务明确要求用户能随时查看、找回API令牌时，才考虑这个方案，它的安全性比哈希低一个档次：

• 核心要求：必须用强加密算法，比如AES-256-GCM，绝对不能用DES这类早就被淘汰的弱算法。
• 密钥管理是关键：加密密钥绝对不能存在数据库里，要放在专门的密钥管理工具（或者应用的安全配置中，绝对不能硬编码到代码里）。
• MariaDB 10.5的实操：可以用AES_ENCRYPT()和AES_DECRYPT()函数，注意要把密钥处理成符合AES要求的长度（16、24或32字节），比如用SHA256(你的密钥)生成32字节的密钥。
• 风险提示：一旦加密密钥泄露，攻击者能解密所有存储的令牌，所以这个方案的安全风险更高，非刚需别用。

总结 #

• 只要业务不需要用户后续查看令牌，直接选哈希存储，这是最安全的做法。
• 如果必须支持令牌查看/找回，再用可逆加密，同时一定要把加密密钥的安全管理做到位。

内容的提问来源于stack exchange，提问作者Andre