REST API的API密钥数据库安全存储方法及最佳实践咨询

针对你提出的三个问题，结合业界通用的安全实践，给出以下具体建议：

1. 是否需要哈希API密钥后存入数据库？ #

必须哈希存储。API密钥属于高敏感的身份凭证，和用户密码的本质是一样的——一旦明文泄露，攻击者就能直接冒充合法用户访问API。哪怕API密钥是系统生成的高熵随机串，也不能低估数据库泄露、内部人员滥用权限等风险，明文存储等于直接把权限拱手相让。

和需要解密的敏感数据（如用户隐私信息）不同，API密钥的验证只需要比对哈希值，不需要反向还原明文，因此哈希是完全适用的方案。

2. 适合哈希API密钥的算法 #

API密钥本身是高熵的（通常是32位以上的随机字符，密钥空间极大），所以不需要像用户密码那样依赖慢哈希算法（如Argon2id）来对抗字典攻击。但为了兼顾安全和易用性，推荐两种方案：

• 方案一：复用密码哈希算法：直接使用Argon2id、bcrypt这类经过严格安全审计的慢哈希算法。虽然对于高熵密钥来说性能开销略有冗余，但能统一身份验证的代码逻辑，且不会降低安全性。
• 方案二：加盐的快速哈希算法：使用SHA-256或SHA-3搭配独立生成的随机盐值。每个API密钥对应唯一盐值，避免彩虹表攻击。示例伪代码：

import hashlib
import os

def hash_api_key(api_key: str) -> tuple[bytes, bytes]:
    # 生成16字节的随机盐值
    salt = os.urandom(16)
    # 盐值拼接密钥后计算SHA-256哈希
    hashed_key = hashlib.sha256(salt + api_key.encode("utf-8")).digest()
    return salt, hashed_key

def verify_api_key(api_key: str, stored_salt: bytes, stored_hash: bytes) -> bool:
    computed_hash = hashlib.sha256(stored_salt + api_key.encode("utf-8")).digest()
    # 用常量时间比对避免时序攻击
    return hashlib.compare_digest(computed_hash, stored_hash)

注意：一定要使用带盐的哈希，绝对禁止使用MD5、SHA-1这类已被破解的算法，也不要用无盐哈希。

3. API密钥存储与管理的特殊注意事项 #

和密码、加密敏感数据相比，API密钥的生命周期和使用场景有明显差异，需要关注以下专属最佳实践：

• 密钥仅展示一次：生成API密钥后，仅向用户展示一次明文，之后系统不再存储任何明文副本。用户丢失密钥后只能重置，无法找回——这和密码不同，用户可以重复输入密码，而API密钥一旦丢失就没有恢复路径。
• 强制密钥轮换机制：支持定期自动轮换或按需手动轮换API密钥，尤其是当用户怀疑密钥泄露时。相比密码，API密钥的轮换成本更低（系统自动生成新密钥，用户只需更新客户端配置）。
• 绑定细粒度权限：每个API密钥最好绑定特定的权限范围（如仅允许访问特定接口、仅具备只读权限），即使密钥泄露，攻击影响范围也能被最小化。这是密码场景下很少用到的逻辑，因为密码通常关联整个用户账号的全量权限。
• 严格限制数据库访问：存储哈希密钥的数据库表，仅允许负责身份验证的服务读取，禁止其他业务服务或内部人员访问。同时启用数据库审计日志，记录所有访问哈希密钥的操作。
• 禁止客户端硬编码：绝对不要将API密钥嵌入前端代码、移动应用安装包中，这类场景应使用OAuth2、JWT等短期凭证方案，而非长期API密钥。
• 不要加密API密钥：除非有特殊业务需求（比如必须恢复明文密钥），否则不要用AES等加密算法存储API密钥——加密需要额外管理加密密钥，反而增加了攻击面，哈希是更安全、更简单的选择。

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