4. 安全考虑

Basic 认证方案不是安全的用户认证方法，也不能以任何方式保护通过物理网络以明文形式传输的实体。HTTP 不阻止向 Basic 认证添加增强功能（例如使用一次性密码的方案）。

Basic 认证最严重的缺陷是它导致用户密码以明文形式在物理网络上传输。许多其他认证方案解决了这个问题。

因为 Basic 认证涉及密码的明文传输，所以不应该（SHOULD NOT）在没有增强功能（如 HTTPS [RFC2818]）的情况下使用它来保护敏感或有价值的信息。

Basic 认证的一个常见用途是用于识别目的——要求用户提供用户 ID 和密码作为识别手段，例如，用于在服务器上收集准确的使用统计信息。当以这种方式使用时，很容易认为如果对受保护文档的非法访问不是主要关注点，那么使用它就没有危险。这只有在服务器向用户同时颁发用户 ID 和密码，并且特别是不允许用户选择自己的密码时才是正确的。危险源于天真的用户经常重用单个密码以避免维护多个密码的任务。

如果服务器允许用户选择自己的密码，那么威胁不仅是对服务器上文档的未授权访问，还包括对用户使用相同密码保护的其他系统上任何其他资源的未授权访问。此外，在服务器的密码数据库中，许多密码也可能是用户在其他站点的密码。因此，如果不以安全方式维护此信息，此类系统的所有者或管理员可能会使系统的所有用户面临对所有其他站点的未授权访问的风险。这引发了安全和隐私方面的担忧 ([RFC6973])。如果相同的用户 ID 和密码组合用于访问其他帐户（如电子邮件或健康门户帐户），则可能会暴露个人信息。

Basic 认证还容易受到伪造服务器的欺骗。如果用户可以被引导相信她正在连接到包含受 Basic 认证保护的信息的主机，而实际上她正在连接到敌对服务器或网关，那么攻击者可以请求密码，将其存储以供以后使用，并假装错误。服务器实现者应该防范这种伪造；特别是，可以接管现有连接上的消息帧控制的软件组件需要谨慎使用或根本不使用（例如：如 [RFC3875] 第 5 节中描述的 NPH（"非解析头"）脚本）。

实现 Basic 认证的服务器和代理需要以某种形式存储用户密码以便对请求进行认证。这些密码应该以某种方式存储，使得密码数据泄漏不会使其变得易于恢复。这在允许用户设置自己的密码时尤其重要，因为已知用户会选择弱密码并在认证领域之间重用它们。虽然对良好的密码哈希技术的完整讨论超出了本文档的范围，但服务器操作员应该努力在密码数据泄漏事件中最小化对其用户的风险。例如，服务器应该避免以明文或未加盐的摘要形式存储用户密码。有关现代密码哈希技术的更多讨论，请参阅"密码哈希竞赛"（https://password-hashing.net）。

使用 UTF-8 字符编码方案和规范化引入了额外的安全考虑；有关更多信息，请参阅 [RFC3629] 的第 10 节和 [RFC5198] 的第 6 节。