4. 安全考虑

Basic 认证方案不是一种安全的用户认证方法, 也不会以任何方式保护实体内容; 该内容会以明文形式在作为承载的物理网络上传输. HTTP 并不阻止为 Basic 认证增加增强机制, 例如使用一次性密码的方案.

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

由于 Basic 认证涉及密码的明文传输, 因此在没有 HTTPS [RFC2818] 等增强机制的情况下, 不应 (SHOULD NOT) 用它来保护敏感或有价值的信息.

Basic 认证的一个常见用途是身份识别, 即要求用户提供用户 ID 和密码作为识别手段, 例如用于收集服务器上的准确使用统计信息. 在这种用法下, 如果非法访问受保护文档并非主要担忧, 人们很容易认为使用它并无危险. 只有当服务器同时向用户发放用户 ID 和密码, 并且尤其不允许用户自行选择密码时, 这种判断才是正确的. 风险来自这样一个事实: 缺乏经验的用户经常重复使用同一个密码, 以避免维护多个密码的麻烦.

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

Basic 认证还容易受到伪造服务器的欺骗. 如果用户被诱导相信自己正在连接到一个包含受 Basic 认证保护信息的主机, 而实际上连接的是恶意服务器或网关, 攻击者就可以请求密码, 将其保存以备后用, 然后伪装成发生错误. 服务器实现者应防范这种伪造; 尤其是, 对于能够接管现有连接上消息分帧控制的软件组件, 需要谨慎使用, 或者完全不使用 (例如 [RFC3875] 第 5 节所述的 NPH ("Non-Parsed Header") 脚本).

实现 Basic 认证的服务器和代理需要以某种形式存储用户密码, 以便对请求进行认证. 这些密码的存储方式应确保即使密码数据泄露, 也不会使密码轻易被恢复. 当允许用户自行设置密码时, 这一点尤其重要, 因为用户往往会选择弱密码, 并在多个认证领域之间重复使用同一密码. 对良好密码哈希技术的完整讨论超出了本文档范围, 但服务器运营者应努力在密码数据泄露时尽量降低用户面临的风险. 例如, 服务器应避免以明文或无盐摘要的形式存储用户密码. 关于现代密码哈希技术的更多讨论, 请参见 "Password Hashing Competition" (````https://password-hashing.net\````).

使用 UTF-8 字符编码方案和规范化会引入额外的安全考虑; 更多信息见 [RFC3629] 第 10 节和 [RFC5198] 第 6 节.

---