Base64 不是加密：安全边界说明

这个页面解决什么问题

很多页面、日志和配置把 Base64 文本显示为一串不可读字符，用户容易误以为它是加密结果。实际 Base64 没有密钥，任何人都能解码。它适合把二进制或复杂文本放进只接受文本的通道，不适合保存密码、隐藏用户资料、保护 token 或替代 HTTPS。

这个说明页用于降低误用风险。工具站如果只提供“编码/解码”按钮而不解释边界，用户可能把编码结果用于错误的安全场景。

快速判断

• 没有密钥参与的转换，通常不是加密。
• 任何在线 Base64 解码器都能还原文本，说明它不具备保密性。
• JWT payload、Basic Auth、data URI 都可能包含可读信息。
• 需要保密时应使用成熟加密方案、密钥管理和访问控制，而不是 Base64。

可复制示例：错误输入与修复后输入

下面的坏样例把密码做 Base64 后保存；修复示例改为说明“不要这样保存”，并使用占位策略描述正确方向。

password = "hunter2" -> aHVudGVyMg== -> store in config

password: use approved secret manager or password hashing; never treat Base64 as protection

Base64 结果只是另一种文本表示。攻击者不需要破解，只要解码即可看到原文。

诊断步骤

1. 明确目标：可传输、可复制、可嵌入，还是保密、认证、完整性。
2. 如果目标是表示字节，可使用 Base64。
3. 如果目标是验证内容未变，可使用哈希或签名。
4. 如果目标是保护密码，应使用专门密码哈希和盐。
5. 如果目标是保护消息内容，应使用经过审查的加密方案和密钥管理。

编码、哈希、签名和加密解决的是不同问题。Base64 只解决“怎样用文本承载字节”，不解决“谁能看”“是否被改”“是否可信”。

常见错误表

常见误判

• 认为“看不懂”就等于加密。
• 把编码结果提交到公开 issue 或文档。
• 在日志中输出 Base64 token，以为不会泄露。
• 把 Base64 与 MD5、AES、签名概念混用。

安全场景的判断标准不是页面能否生成一串文本，而是是否有密钥、权限、验证和审计。Base64 没有这些机制。

隐私、安全和适用边界

本页不提供加密实现方案，只用于说明 Base64 的能力边界。涉及凭证、支付、身份认证、隐私数据和安全协议时，应遵循团队安全规范和官方库。

复制或发布前复核清单

1. 目标是否只是文本传输。
2. 是否有任何人可以解码得到原文。
3. 是否误把 Base64 当成密码保护。
4. 是否在样本中移除真实 token 和凭证。
5. 是否需要哈希、签名或加密而不是编码。
6. 是否在文档中明确“Base64 不是加密”。

相关工具和延伸阅读

参考依据

• RFC 4648：Base64 是编码方案。
• OWASP 安全实践：密码和密钥不应以可逆编码保护。
• Ymir Tool MD5 指南：摘要与安全边界区分。