C7：保护数字身份

描述

数字身份是个人、组织（或其他主体）在进行在线交易时的独特表示。认证是验证个人或实体是否如其所声称的身份的过程。

会话管理是服务器维护用户认证状态的过程，以便用户可以继续使用系统而无需重新认证。数字身份、认证和会话管理是非常复杂的主题。我们在此只触及了数字身份话题的皮毛。请确保您最有能力的工程人才负责维护大多数身份解决方案所涉及的复杂性。

《NIST 特别出版物 800-63B：数字身份指南（认证与生命周期管理）》为数字身份、认证和会话管理控制的实施提供了可靠的指导。以下是一些安全实施的建议，以确保应用程序中实施了强大的数字身份控制。

认证保障级别

NIST 800-63b 描述了三种认证保障级别，称为认证保障级别 (AAL)

级别 1：密码

第一个级别，AAL 级别 1，适用于不包含 PII 或其他私人数据的低风险应用程序。在 AAL 级别 1，仅需要单因素认证，通常通过使用密码（您已知的事物）实现。密码（或一般凭证）的安全性至关重要，这包括安全存储（使用密钥派生函数等）以及相应的流程，例如拥有安全的密码重置流程。

级别 2：多因素认证

NIST 800-63b AAL 级别 2 适用于包含“自我声明的 PII 或其他在线提供的个人信息”的较高风险应用程序。在 AAL 级别 2，需要多因素认证，包括 OTP 或其他形式的多因素实现。

多因素认证 (MFA) 通过要求用户结合以下方式验证身份，确保用户是其所声称的身份：

您已知的事物 – 密码或 PIN
您拥有的事物 – 令牌或手机；使用手机时，请使用遵循 FIDO2 等标准化协议的标准认证应用程序。
您本身 – 生物识别，例如指纹

单独使用密码作为认证因素提供的安全性较弱。多因素解决方案通过要求攻击者获取多个要素才能通过服务认证，从而提供更强大的解决方案。

值得注意的是，生物识别技术在用作单一认证因素时，不被视为数字认证的可接受秘密。它们可以通过在线获取、使用拍照手机在当事人知情或不知情的情况下拍摄（例如面部图像）、从当事人触摸的物体上提取（例如潜在指纹），或通过高分辨率图像捕获（例如虹膜图案）。生物识别必须仅作为多因素认证的一部分，并结合物理认证器（您拥有的事物）使用。例如，访问多因素一次性密码 (OTP) 设备将生成一次性密码，用户手动输入该密码以供验证器验证。

级别 3：基于密码学的认证

当受损系统的影响可能导致人身伤害、重大经济损失、损害公共利益或涉及民事或刑事违法行为时，需要 NIST 800-63b 认证保障级别 3 (AAL3)。AAL3 要求认证“基于通过密码协议证明密钥所有权”。这种类型的认证用于实现最强的认证保障级别。这通常通过硬件密码模块完成。在开发 Web 应用程序时，这通常会涉及到 WebAuthn 或 PassKeys。

会话管理：客户端会话与服务器端会话

HTTP 本身是一个无状态协议：请求之间不共享数据。然而，当我们审视如何使用 Web 时，这显然与用户所见不同，例如，您登录一个网站后，在后续请求中仍保持登录状态。这是因为会话管理已在 HTTP 之上实现。

一旦初始用户认证成功，应用程序可以选择在有限的时间内跟踪并维护此认证状态。这将允许用户继续使用应用程序，而无需在每个请求中重新认证。这种用户状态的跟踪被称为会话管理。

会话管理大致可分为客户端会话管理和服务器端会话管理。前者将所有会话数据存储在客户端，并在每个请求中传输到服务器。后者将特定于会话的数据存储在服务器端，例如在数据库中，并且只向客户端传输一个标识符。客户端随后在每个请求中只提交会话标识符，服务器则从服务器端存储中检索会话数据。

从安全角度来看，服务器端会话具有多重优势：

数据不直接存储在客户端：这可能带来问题，例如在处理敏感数据时。此外，客户端会话管理解决方案必须确保客户端数据未被篡改。
客户端和服务器之间传输的数据量更少（由于网络带宽的增加，这一点已不那么重要）
服务器端会话管理允许会话失效，例如用户可以注销其所有会话。默认情况下，始终使用服务器端会话管理。

威胁

攻击者可能通过窃取或预测会话令牌来劫持用户会话，从而可能未经授权访问已认证的用户账户。
攻击者可能通过利用弱会话管理执行会话固定攻击，强制用户使用已知的会话标识符。
攻击者可能对已认证的会话执行跨站请求伪造 (CSRF) 攻击，诱骗用户在不知情的情况下在 Web 应用程序上执行不希望的操作。

实施

使用密码时

密码要求

密码至少应符合以下要求：

如果也使用了多因素认证 (MFA) 和其他控制措施，长度应至少为 8 个字符。如果无法使用 MFA，则应增加到至少 10 个字符。
所有可打印的 ASCII 字符以及空格字符都应在记忆的秘密中被接受。
鼓励使用长密码和密码短语。
取消复杂性要求，因为已发现这些要求效果有限。相反，建议采用 MFA 或更长的密码长度。
确保所使用的密码不是先前泄露过的常用密码。您可以选择阻止符合上述长度要求并在泄露密码列表中发现的前 1000 或 10000 个最常用密码。以下链接包含最常见的密码：https://github.com/danielmiessler/SecLists/tree/master/Passwords
强制密码轮换，以避免因长期使用相同密码而可能导致的安全漏洞。

实现安全的密码恢复机制

应用程序通常会有一个机制，允许用户在忘记密码时重新获得对其账户的访问权限。一个好的密码恢复功能设计流程将使用多因素认证元素。例如，它可能会问一个安全问题——他们已知的事物，然后向设备发送一个生成的令牌——他们拥有的事物。

更多详细信息请参阅《OWASP 忘记密码备忘单》和《OWASP 选择和使用安全问题备忘单》。

实现安全的密码存储

为了提供强大的认证控制，应用程序必须安全地存储用户凭证。此外，应设置加密控制，以便即使凭证（例如密码）被泄露，攻击者也无法立即访问这些信息。更多详细信息请参阅《OWASP 密码存储备忘单》。

服务器端会话管理

通常，服务器端会话管理通过 HTTP cookie 实现，HTTP cookie 用于存储会话标识符。当请求新会话时，服务器会生成一个新的会话标识符并将其传输给客户端（浏览器）。在每个后续请求中，会话标识符从客户端传输到服务器，服务器使用此会话标识符在服务器端数据库中查找会话数据。

会话生成与过期

用户状态在会话中进行跟踪。对于传统的基于 Web 的会话管理，此会话通常存储在服务器上。然后将一个会话标识符提供给用户，以便用户能够识别哪个服务器端会话包含正确的用户数据。客户端只需维护此会话标识符，这也使得敏感的服务器端会话数据不存储在客户端。

以下是在构建或实施会话管理解决方案时需要考虑的一些控制措施：

确保会话 ID 足够长、唯一且随机，即具有高熵值。
应用程序应在认证和重新认证期间生成新会话。
应用程序应在一段不活动期后实现空闲超时，并为每个会话设置一个绝对最长生命周期，之后用户必须重新认证。超时时长应与受保护数据的价值成反比。

更多详细信息请参阅《会话管理备忘单》。ASVS 第 3 节涵盖了额外的会话管理要求。

客户端会话管理

服务器端会话对于某些形式的认证可能具有局限性。“无状态服务”允许客户端管理会话数据以提高性能，从而减轻服务器存储用户会话的负担。

这些“无状态”应用程序通常会生成一个短寿命的访问令牌，其中包含当前用户的所有访问权限，该令牌随后会包含在所有后续请求中。必须采用加密技术，以防止客户端篡改令牌中存储的权限。当客户端请求服务器操作时，客户端会包含检索到的访问令牌，服务器会验证该令牌是否未被篡改，并从令牌中提取权限。这些权限随后用于后续的权限检查。

JWT (JSON Web 令牌)

JSON Web Token (JWT) 是一个开放标准（RFC 7519），它定义了一种紧凑、自包含的方式，用于在各方之间以 JSON 对象的形式安全地传输信息。只要信息经过受信任机构的数字签名，就可以验证并信任。JWT 令牌在认证期间创建，并在任何处理之前由服务器（或多个服务器）进行验证。然而，JWT 在初次创建后通常不会被服务器保存。JWT 通常是在创建后直接交给客户端，而不会被服务器以任何方式保存。令牌的完整性通过数字签名来维护，因此服务器以后可以验证 JWT 仍然有效，并且自创建以来未被篡改。

这种方法既无状态又可移植，意味着客户端和服务器技术可以不同但仍能相互作用。

请注意，如果您正在使用 JWT，您必须确保返回的 JWT 确实使用了您正在使用的签名算法之一。否则，攻击者可能会尝试使用 NULL 算法签名的 JWT，利用 MAC-与-签名混淆攻击，或提供自定义 JWS 密钥进行签名。在您颁发 JWT 时，务必确保您正在使用安全的私钥对 JWT 进行签名：每个输出的 JWT 都为攻击者提供了执行离线破解攻击所需的所有信息，因此您也应该经常轮换密钥。

浏览器 Cookie

浏览器 cookie 是 Web 应用程序存储会话标识符的常用方法，用于实现标准会话管理技术的 Web 应用程序。以下是使用浏览器 cookie 时需要考虑的一些防御措施。

当浏览器 cookie 用作跟踪已认证用户会话的机制时，这些 cookie 应仅限于最小的域和路径集可访问，并且应标记为在会话有效期结束时或之后不久过期。
请注意，在 cookie 设置期间未明确指定域将使用当前源作为域。这是一个合理的默认设置。
请注意，在 cookie 设置期间指定路径将限制浏览器仅在请求位于指定路径内时才提交 cookie。这可以保护一个应用程序的 cookie 不被同一服务器上不同路径中的另一个应用程序访问。这种保护是脆弱的：如果“另一个”应用程序存在 XSS 漏洞，并且攻击者可以引入 iframe，则“路径”保护可能会被规避。
应设置“secure”标志，以确保传输仅通过安全通道（TLS）进行。
应设置 HttpOnly 标志，以防止通过 JavaScript 访问 cookie。
为 cookie 添加“SameSite”属性可以阻止一些现代浏览器在跨站请求中发送 cookie，并提供针对跨站请求伪造和信息泄露攻击的保护。

防止的漏洞

参考资料

工具

Daniel Miessler：最常见密码