简短回答
基本认证的安全性取决于其运行的传输层。在 HTTPS 上，它对许多实际系统是可接受的。在纯 HTTP 上，它实际上是在以明文形式发送密码。该方案本身不提供机密性——因此安全讨论实际上围绕如何部署它。
为什么 Base64 不是安全措施
Authorization: Basic YWRtaW46c2VjcmV0MTIz 中的凭据只是 Base64，任何人都可以一步解码：
echo 'YWRtaW46c2VjcmV0MTIz' | base64 --decode
# admin:secret123
Base64 是一种编码，而非加密——没有密钥。将捕获的 Authorization 头部视为完全暴露的凭据。这是关于基本认证最常被误解的一点。
真实风险
- 通过 HTTP 传输明文。 没有 TLS，每个请求都会将密码泄露给网络路径上的任何人。不可妥协：使用 HTTPS。
- 凭据日志记录。 Web 服务器、代理和 CDN 通常会记录请求头部。Authorization 头部（以及密码）可能以明文形式出现在日志中，除非你将其编辑掉。
- 无法注销。 浏览器会缓存会话的基本凭据；没有服务器端的方法可以使其失效，除非更改密码。
- 每个请求的重放。 由于每次发送相同的凭据，单个泄露的请求会导致永久性妥协，直到密码更改——这与短期的 Bearer 令牌 不同。
- 无作用域。 凭据是全有或全无；无法授予有限访问权限。
使其可接受的最佳实践
- 始终使用 HTTPS。 完全拒绝通过 http 的基本认证。
- 每个客户端凭据。 为每个消费者提供独立的用户名/密码，以便在不影响其他用户的情况下撤销一个。
- 存储哈希，而非密码。 在服务器端使用 bcrypt/argon2 哈希进行验证。
- 在访问日志和错误追踪器中编辑 Authorization 头部。
- 定期轮换，并将基本认证限制在低敏感度或内部资源上。
- 添加网络控制——VPN、IP 白名单或 WAF——用于任何重要资源。
何时选择其他方案
如果你需要过期访问、按用户权限或无需更改密码即可撤销，请改用 Bearer 令牌——参见 基本认证 vs Bearer 令牌 和 OAuth 2.0 与 OpenID Connect。对于消费者应用中的最终用户登录，基本认证是错误的工具。
常见问题
HTTP 基本认证安全吗？ 仅在 HTTPS 上安全。Base64 是可逆的，因此没有 TLS，密码实际上以明文形式传输。使用 TLS 加上每个客户端凭据和头部编辑，基本认证对于内部和机器对机器 API 是可接受的。
Base64 编码是加密吗？ 不是。Base64 没有密钥，任何人都可以解码。它本身不提供任何机密性。
我可以在生产环境中使用基本认证吗？ 可以，对于内部或服务间 API，在 HTTPS 上并遵循适当的凭据卫生。避免在面向公众的应用中用于最终用户认证。
使用 基本认证生成器 生成和检查基本认证头部，并在 HTTP 基本认证：工作原理 中查看完整方案。