跳过内容

C6：实施数字身份

该控制措施的新版本已发布！

您正在查看OWASP十大主动控制的旧版2018年版本。您可以在OWASP十大主动控制2024中的C7：保护数字身份中找到有关相同控制的信息！

描述

数字身份是用户（或其他主体）在进行在线交易时的独特表示。认证是验证个人或实体是否如其所声称的身份的过程。会话管理是服务器维持用户认证状态的过程，以便用户可以继续使用系统而无需重新认证。NIST 特别出版物800-63B：数字身份指南（认证和生命周期管理）为实施数字身份、认证和会话管理控制提供了可靠的指导。

以下是一些安全实施的建议。

认证级别

NIST 800-63b描述了三个认证保障级别（AAL）。AAL级别1适用于不包含个人身份信息（PII）或其他私有数据的低风险应用程序。在AAL级别1，通常只需通过密码进行单因素认证。

级别1：密码

密码非常非常重要。我们需要策略，需要安全地存储它们，有时还需要允许用户重置它们。

密码要求

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

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

实现安全的密码恢复机制

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

更多详情请参阅忘记密码备忘单和选择和使用安全问题备忘单。

实现安全的密码存储

为了提供强大的认证控制，应用程序必须安全地存储用户凭据。此外，应设置密码控制措施，以便即使凭据（例如密码）被泄露，攻击者也无法立即访问此信息。

PHP密码存储示例

以下是使用password_hash()函数（5.5.0版本及以上可用，默认使用bcrypt算法）在PHP中进行安全密码哈希的示例。该示例使用了15的工作因子。

<?php
 $cost = 15;
 $password_hash = password_hash("secret_password", PASSWORD_DEFAULT,["cost" => $cost]);
?>

更多详情请参阅OWASP密码存储备忘单。

级别 2：多因素认证

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

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

  • 您已知的事物 – 密码或 PIN
  • 您拥有的东西 – 令牌或手机
  • 您本身 – 生物识别，例如指纹

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

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

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

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

会话管理

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

会话生成与过期

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

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

  • 确保会话ID是长、唯一且随机的。
  • 应用程序应在认证和重新认证期间生成新会话或至少轮换会话ID。
  • 应用程序应在一段时间不活动后实施空闲超时，并为每个会话设置一个绝对最大生命周期，在此之后用户必须重新认证。超时时长应与受保护数据的价值成反比。

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

浏览器 Cookie

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

  • 当浏览器Cookie用作跟踪已认证用户会话的机制时，它们应该仅限于最小的域和路径集可访问，并且应标记为在会话有效期到期时或之后不久过期。
  • 应设置“secure”标志，以确保仅通过安全通道（TLS）进行传输。
  • 应设置 HttpOnly 标志，以防止通过 JavaScript 访问 cookie。
  • 向Cookie添加“SameSite”属性可防止某些现代浏览器随跨站请求发送Cookie，并提供针对跨站请求伪造和信息泄露攻击的保护。

令牌

服务器端会话对某些形式的认证可能存在限制。“无状态服务”允许客户端管理会话数据以提高性能，从而减轻服务器存储和验证用户会话的负担。这些“无状态”应用程序会生成一个短生命周期的访问令牌，该令牌可用于认证客户端请求，而无需在初始认证后发送用户凭据。

JWT (JSON Web 令牌)

JSON Web Token (JWT) 是一个开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间以JSON对象形式安全传输信息。此信息可以通过数字签名进行验证和信任。JWT令牌在认证期间创建，并在任何处理之前由服务器（或多个服务器）进行验证。

然而，JWT在初始创建后通常不会被服务器保存。JWT通常是在创建后直接交给客户端，而不会被服务器以任何方式保存。令牌的完整性通过数字签名来维护，因此服务器可以在以后验证JWT是否仍然有效且自创建以来未被篡改。

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

注意：数字身份、认证和会话管理是非常大的主题。我们在此只是触及了数字身份主题的表面。请确保您最有能力的工程人才负责维护大多数身份解决方案所涉及的复杂性。

防止的漏洞

参考资料

工具