C7：保护数字身份

描述

数字身份是个人、组织（或其他主体）参与在线交易时的唯一标识。身份验证是验证个人或实体是否是其声称身份的过程。

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

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

身份验证保证级别

NIST 800-63b 描述了三个身份验证保证级别，称为身份验证保证级别 (AAL)

级别 1：密码：第一个级别，AAL 级别 1 适用于不包含 PII 或其他私人数据的低风险应用程序。在 AAL 级别 1，仅需要单因素身份验证，通常通过使用密码（您所知道的）来实现。密码（或一般凭据）的安全性至关重要，这包括安全存储（使用密钥派生函数等）以及相应的流程，例如拥有安全的密码重置流程。
级别 2：多因素身份验证：NIST 800-63b AAL 级别 2 适用于包含“自声明 PII 或在线提供的其他个人信息”的较高风险应用程序。在 AAL 级别 2，需要多因素身份验证，包括 OTP 或其他形式的多因素实现。
级别 3：基于密码学的身份验证：当受损系统的影响可能导致人身伤害、重大经济损失、损害公共利益或涉及民事或刑事违法行为时，需要 NIST 800-63b 身份验证保证级别 3 (AAL3)。AAL3 要求身份验证“基于通过密码协议证明密钥所有权”。这种类型的身份验证用于实现最强的身份验证保证级别。这通常通过硬件密码模块完成。在开发 Web 应用程序时，这通常会涉及到 WebAuthn 或 PassKeys。

级别 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 本身是一个无会话协议：请求之间不共享数据。当我们查看网络的使用方式时，这显然与用户所见的并不一致，例如，您登录一个网站后在后续请求中保持登录状态。这之所以可能，是因为会话管理已在 HTTP 之上实现。

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

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

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

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

威胁

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

实施

使用密码时

密码要求

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

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

实现安全的密码恢复机制

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

欲了解更多详情，请参阅《忘记密码速查表》和《选择和使用安全问题速查表》。

实现安全的密码存储

为了提供强大的身份验证控制，应用程序必须安全地存储用户凭据。此外，应到位加密控制，以便即使凭据（例如密码）受到威胁，攻击者也无法立即访问此信息。欲了解更多详情，请参阅《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 不被同一服务器上不同路径中的另一个应用程序访问。这种保护是脆弱的：如果“其他”应用程序存在 XSS 漏洞并且攻击者可以引入 iframe，则“路径”保护可能会被规避。
应设置“secure”标志以确保仅通过安全通道（TLS）进行传输。
应设置 HttpOnly 标志，以防止通过 JavaScript 访问 cookie。
为 cookie 添加“SameSite”属性可以阻止某些现代浏览器随跨站请求发送 cookie，并提供针对跨站请求伪造和信息泄露攻击的保护。

防止的漏洞

参考资料

工具

Daniel Miessler：最常见密码