认证授权与会话安全

• 密码长度优先于复杂度，口令与密码本检查
• 限制密码尝试次数、强制 MFA
• 认证器的分级（单因素/多因素）

NIST SP 800-63B 是《数字身份指南》中关于认证（Authenticator）与生命周期管理的部分，为密码和认证策略提供了权威建议。其核心变化包括：1）密码策略上"长度优先于复杂度"——建议至少 8 位（可更长），不再强制要求随意的大小写/数字/符号组合，因为研究表明复杂度要求反而导致用户使用可预测的弱密码；2）要求对用户密码做"已知泄露密码"（如被脱库的密码）检查，拒绝已在已知泄露列表中的口令；3）不强制密码定期过期（除非有泄露迹象），避免用户频繁更换导致弱密码；4）限制认证失败尝试次数（防暴力破解），配合速率限制；5）强制推荐 MFA（多因素认证），提倡使用基于 WebAuthn 的安全密钥、TOTP 等；6）安全存储：使用加盐哈希（如 bcrypt、scrypt、Argon2）存储密码，禁止明文或可逆加密。这些建议推动了业界从"复杂度强制"转向"长度 + 泄露检查 + MFA"的现代认证实践。

NIST 800-63B 的核心理念是"以用户行为规律与安全工程事实为依据"。答题要抓住"长度优先、泄露检查、限制尝试、MFA、加盐哈希"这几个要点，并指出与传统"复杂度+定期更换"策略的差异。

• PKCE：防止授权码拦截（公开客户端）
• state 参数：防止 CSRF（授权码替换）
• redirect_uri 白名单：防止授权码被重定向到攻击者

这三个机制分别防御 OAuth 2.0 授权流程中的三类攻击。PKCE（RFC 7636，Proof Key for Code Exchange）：客户端在发起授权请求时生成 code_verifier 并计算其 SHA-256 变换 code_challenge，用授权码换取 token 时再提交 code_verifier，授权服务器校验两者是否匹配。它用于防止授权码被拦截后复用（尤其适用于无法保密 client_secret 的公开客户端，如单页应用），即使授权码被截获，没有 verifier 也无法换取 token。state 参数：客户端在授权请求中生成随机 state，在回调中校验其一致，用于防止 CSRF"授权码替换攻击"（攻击者用自己换来的授权码注入受害者的会话）。redirect_uri 白名单：授权服务器只允许把授权码发给预先注册的、精确匹配的 redirect_uri，防止攻击者通过篡改 redirect_uri 把授权码重定向到恶意地址而被窃取。三者配合是 OAuth 2.0 安全落地的基础。

PKCE 防"授权码拦截/复用"，state 防"CSRF/授权码替换"，redirect_uri 白名单防"授权码被重定向到恶意站点"。三者看向授权流程的不同环节，答题要分别对应"哪个攻击"。

• 四种授权模式的角色与流程
• 适用场景与安全级别
• 现代推荐：Authorization Code + PKCE，弃用 Implicit/Password

OAuth 2.0（RFC 6749）定义了四种授权模式。Authorization Code（授权码模式）：最常用，客户端先获取授权码再换取令牌，适用于服务端应用与现代原生/SPA（配合 PKCE），安全级别最高，令牌不直接暴露给用户浏览器。Client Credentials（客户端凭证模式）：客户端用自己的 client_id+secret 直接换取令牌，适用于服务端到服务端的机器对机器通信（无用户）。Implicit（隐式模式）：令牌直接通过重定向返回浏览器，不经过授权码，因令牌暴露在 URL 且无客户端认证，已不推荐（被 PKCE 的授权码模式取代）。Password（密码模式）：用户直接向客户端提供用户名密码，客户端用其换取令牌，仅适用于高信任的一等客户端（常被弃用，因为客户端会接触明文密码）。安全取舍上，现代最佳实践是：优先 Authorization Code + PKCE，机器通信用 Client Credentials，避免使用 Implicit 与 Password 模式。

答题要抓住"是否有用户、客户端是否可信、令牌是否暴露给浏览器"。Authorization Code + PKCE 是主流，Implicit/Password 因安全缺陷被弃用。Client Credentials 用于无用户场景。

• A07 的问题：弱认证、会话固定、凭证泄露、枚举
• 预防：强密码策略、MFA、会话管理、防暴力破解
• 认证失败与授权失败的边界

OWASP A07（Identification and Authentication Failures）涵盖所有与身份认证和会话管理相关的失败，包括：弱认证（弱密码、未强制 MFA）、凭证泄露（密码明文存储、硬编码）、会话管理缺陷（会话固定、会话过期不当、会话 ID 泄露）、认证绕过与枚举（账号枚举、暴力破解未限制）、可预测的认证凭据等。预防措施包括：实现强密码与防暴力破解（长度策略、尝试次数限制、速率限制、验证码）、强制 MFA（尤其管理员与高价值账户）、安全存储密码（加盐哈希如 bcrypt/Argon2）、安全的会话管理（会话 ID 轮换、HttpOnly+Secure+SameSite cookie、合理过期与空闲超时）、认证失败统一错误提示（不泄露账号是否存在）、对敏感操作二次认证、使用安全的认证框架并避免自行实现认证逻辑、定期审计日志。

A07 是把"认证失败"作为一个大类，涵盖身份、密码、凭证、会话的失败。答题要覆盖"认证、密码存储、会话、防爆破、MFA"五大抓手，并区分认证（who）与授权（what）。

• OIDC 是 OAuth 2.0 之上的身份认证层
• ID Token（JWT）承载用户身份声明
• UserInfo 端点与 Discovery（.well-known/openid-configuration）

OpenID Connect（OIDC）是构建在 OAuth 2.0 之上的"身份认证层"：OAuth 2.0 只负责授权（获取访问令牌以访问资源），而 OIDC 增加了"认证用户并传递身份信息"的能力。它引入的关键组件：ID Token——一个 JWT，由授权服务器签发，包含用户的身份声明（sub 用户标识、iss 签发者、aud 受众、exp 过期、nonce 等），客户端可离线验证其签名与声明完成用户认证；UserInfo 端点——客户端（有 access token）可调用它获取更完整的用户资料（姓名、邮件、头像等）；Discovery 文档——通过 /.well-known/openid-configuration 提供授权服务器元数据（授权端点、token 端点、签发者、JWKS 地址等），客户端可自动发现并配置。OIDC 还定义了认证流程（Authorization Code Flow、Implicit Flow、Hybrid Flow）与 scope（openid、profile、email）。简单说：OAuth 管"能访问什么"，OIDC 管"你是谁"。

核心是 OIDC 给 OAuth 加上"身份"。ID Token 是认证结果（JWT），UserInfo 是资料接口，Discovery 是元数据自动发现。答题要区分"ID Token 认证 vs Access Token 授权"。

• 认证：确认"你是谁"（身份验证）
• 授权：确认"你能做什么"（权限授予）
• 两者先后关系与混用风险

认证（Authentication）回答"who are you"——确认用户身份是否真实，常见手段包括密码、MFA、令牌、证书；授权（Authorization）回答"what can you do"——确认已认证的用户是否有权限访问某个资源或执行某个操作，常见手段包括 RBAC、ABAC、ACL、OAuth 作用域。两者是"先认证、后授权"的顺序关系：必须先确认身份，再依据身份判断权限。混淆两者的风险很高：例如"用户已登录"（认证成功）不等于"有权访问该资源"（授权失败），若只做认证不做授权检查，会导致越权访问（IDOR 等）。错误消息上也需区分：认证失败返回 401（Unauthorized，实际指未认证），授权失败返回 403（Forbidden）。因此设计上要明确身份管理（登录、会话）与权限管理（角色、策略、资源校验）的边界，避免把"登录了"当作"有权限"。

记忆点是"who vs what"。认证确认身份，授权决定权限，顺序是认证→授权。答题强调"登录≠有权限"和 401/403 的区分。

• JWT 三段结构：header.payload.signature
• alg=none 绕过：服务端未校验签名算法
• 弱密钥爆破：HS256 使用弱密钥可被爆破

JWT（JSON Web Token）由三段用 . 分隔的 Base64url 编码组成：header.payload.signature。header 含算法（alg）与类型；payload 含声明（sub、exp、iat、scope 等）；signature 用 header 声明的算法对 header.payload 签名。常见攻击：1）alg=none 绕过——若服务端接受 alg:none 且不校验签名，攻击者可伪造无签名 token；2）弱密钥爆破——HS256（对称）使用弱密钥时，攻击者可离线爆破出 HMAC 密钥并伪造 token；3）算法混淆——服务端信任 header 中的 alg，攻击者把 RS256（非对称）改成 HS256（对称），并用服务器已公开的 RSA 公钥作为 HS256 的 HMAC 密钥来签名，若服务端错误地接受该对称签名，即可伪造 token。防御：服务端固定并校验允许的算法（白名单，禁 none）、密钥强度足够且保密、区分对称/非对称密钥、校验签名与 exp、对 token 做时间窗校验。现代建议用强签名算法（如 RS256/ES256）并严格验证 alg 白名单。

这三类攻击都源于"服务端未严格校验算法与签名"。答题要点：固定 alg 白名单、禁 none、密钥管理、校验签名和过期。理解"算法混淆"需要区分对称/非对称的本质。

• 会话固定原理：攻击者诱使用户使用已知的会话 ID
• 登录后轮换会话 ID：消除攻击者已知的会话
• 防御：重新生成 session ID、HttpOnly、过期

会话固定（Session Fixation）攻击指攻击者预先设置一个会话 ID（如通过 URL、cookie 注入），诱使受害者使用该会话 ID 登录，登录后攻击者仍持有该 ID，从而共享/劫持受害者的已认证会话。根因是"登录前后会话 ID 不变"，攻击者已知的 ID 在登录后仍有效。防御核心是"登录后轮换会话 ID"（Session Fixation Protection）：用户在成功认证（登录/权限提升）后，服务器必须重新生成一个新的会话 ID，废弃旧的，使攻击者预置的 ID 失效。此外还需：会话 ID 使用强随机值、通过 HttpOnly+Secure+SameSite cookie 传输、设置合理过期、空闲超时、登录/登出时显式销毁旧会话。配合 OWASP 建议，会话 ID 应只在登录后生成并绑定，不在登录前固定。

"登录后轮换会话 ID"是会话固定防御的标志性措施。答题强调"认证成功时必须重新生成会话 ID"，并辅以 cookie 安全属性与过期管理。

• HttpOnly：阻止 JS 读取，防 XSS 窃取会话
• Secure：仅 HTTPS 传输，防中间人嗅探
• SameSite：限制跨站携带，防 CSRF

Cookie 的三个安全属性各司其职：HttpOnly——标记后浏览器禁止 JavaScript 读取该 cookie（document.cookie 拿不到），防止 XSS 窃取会话 cookie，是"XSS 窃取会话"的核心防线；Secure——浏览器只在 HTTPS 连接上发送该 cookie，防止明文 HTTP 传输中被中间人嗅探；SameSite——控制 cookie 在跨站请求中是否携带，SameSite=Lax（默认，跨站顶级导航会带，跨站子请求不带）或 Strict（所有跨站请求都不带）可阻断大部分 CSRF。工程配置：会话 cookie 应同时设置 HttpOnly; Secure; SameSite=Lax（或按需 Strict），并配合 Path、Domain（尽量不设泛域）、合理的 Max-Age/Expires。安全注意：Secure 需站点全站 HTTPS 才有效；SameSite 不能替代 CSRF token（对某些场景仍不够）；敏感 cookie 不放 JS 可读的 localStorage。

三个属性分别防 XSS 窃取、中间人嗅探、CSRF。答题要"属性→防御目标"一一对应，并强调三者叠加配置。HttpOnly 与 XSS、SameSite 与 CSRF 是高频考点。

• 各哈希算法的参数维度
• 调优目标：增加暴力破解成本且不显著影响用户体验
• 参数与硬件/延迟的平衡

密码哈希算法通过参数控制计算成本，使暴力破解每个候选密码都需付出可观代价。bcrypt 用 cost（work factor，即 2 的幂次迭代轮数，如 10~14）；scrypt 用 N（memory cost，内存开销）、r（block size）、p（parallelism，并行度）；Argon2 有 m_cost（memory cost）、t_cost（iterations）、p（parallelism）。调优原则：参数应"尽可能高"以对抗 GPU/ASIC 暴力破解，但又要保证单次认证延迟在可接受范围（通常目标 <1 秒，且考虑峰值流量）。调优方法：在目标硬件上基准测试，逐步提高参数直至延迟接近上限，同时考虑内存与并行度的成比例增长；Argon2 首选 Argon2id（综合抗侧信道与抗 GPU）。参数应随硬件发展定期上调（如每年重新评估），并随哈希一起存储（便于未来升级迁移）。注意 parallelism 并非越高越好，要结合攻击模型与内存带宽。

参数调优是"安全成本 vs 延迟"的平衡。答题要点：各算法的参数名、目标延迟、基准测试、定期上调、随哈希存储。这是工程落地的关键题。

• 三者都是慢哈希、抗 GPU 的密码哈希
• Argon2 是内存硬型、有抗侧信道优势，为 PHC 推荐
• 选择考虑：语言生态、参数可调、兼容性

bcrypt、scrypt、Argon2 都是专为密码存储设计的"慢哈希"，通过增加计算与内存成本抵抗 GPU/ASIC 暴力破解。bcrypt：最成熟、生态最广（几乎所有语言都有实现），基于 Blowfish，抗 GPU 好，但内存占用固定、对大规模并行 ASIC 相对较弱；scrypt：内存硬型（memory-hard），通过消耗大量内存提高抗 ASIC 能力，但有侧信道顾虑（如缓存时序）；Argon2：PHC（Password Hashing Competition）获胜者，内存硬型且设计上抗侧信道，其中 Argon2id 是综合推荐（兼具抗侧信道与抗 GPU），参数可调（内存、时间、并行），是当前最现代的密码哈希选择。工程选择建议：若生态与兼容性优先且无特定要求，Argon2id 是首选；若需广泛兼容或服务端受限，bcrypt（cost 足够）仍可接受；不要使用 MD5/SHA-1/SHA-256 等快速哈希（未加盐、无慢化）或可逆加密存储密码。所有方案都应加盐（唯一随机盐）并采用合适参数。

选择核心是"慢哈希 + 内存硬 + 抗侧信道 + 生态"。Argon2id 最推荐，bcrypt 最成熟，scrypt 居中。答题强调"禁用快速哈希、必须加盐、参数可调"。

• Session：服务端状态、简单、易撤销
• Token（JWT）：无状态、可扩展、撤销难
• SSO：单点登录、跨域身份

三种认证方案各有取舍。Session-based：服务端保存会话状态（内存/存储），客户端只持 session ID，认证简单、易撤销（删会话即可）、天然兼容服务端会话管理，但需会话存储、水平扩展时需共享会话（粘性会话或分布式存储），且多服务/多域需处理会话共享。Token-based（典型 JWT）：无状态（token 自包含声明），便于水平扩展与跨服务鉴权，客户端存储 token，但撤销难（无状态无法即时失效，需短有效期+refresh 或黑名单），且需严格控制 token 存储安全（防 XSS 窃取）。SSO（Single Sign-On）：基于标准（OAuth 2.0/OIDC/SAML）实现跨系统一次登录多处访问，统一身份源，改善用户体验与安全集中管理，但引入身份提供商依赖、实现复杂、需处理协议与信任。取舍：单应用简单场景用 Session 或 Token；微服务/多端用 Token；组织多系统统一身份用 SSO（可结合 OIDC 与 Token）。实际常组合：SSO 负责认证，Token 负责服务间授权。

取舍关键是"状态管理位置"与"撤销/扩展性"。答题要对比 Session 状态性、Token 无状态、SSO 集中身份，并说明组合用法。

• localStorage：JS 可读，易受 XSS 窃取
• HttpOnly cookie：防 XSS 窃取，但需配 CSRF 防护
• 权衡与配套措施

令牌存储方式直接影响安全风险。localStorage/sessionStorage：token 存于此，JS 可直接读取（localStorage.getItem），一旦存在 XSS，token 可被窃取并离线使用，且 token 常无失效保护，风险高；其优势是实现简单、无 CSRF 问题（token 由 JS 显式携带，不自动附带）。HttpOnly cookie：浏览器自动携带且 JS 不可读，有效防 XSS 窃取令牌，但正是"自动携带"导致此类 cookie 有 CSRF 风险（跨站请求自动带 cookie），需配置 SameSite 和/或 CSRF token 防护。权衡：两者都可行，关键是"接受哪个攻击面"。常见现代建议：主访问令牌（access token）放内存（JS 变量）而非 localStorage，配合短生命周期与 HttpOnly 的 refresh token cookie；或干脆用 HttpOnly cookie 存会话并配 CSRF token。核心是"不要在 localStorage 存高价值、长生命周期令牌"，并同时对 XSS 与 CSRF 做纵深防御。

关键理解是"localStorage 抗 CSRF 但易 XSS 窃取，HttpOnly cookie 抗 XSS 窃取但需 CSRF 防护"。答题要分析两者攻防面并给出组合建议。

• JWT 无状态使失效（登出、改密）难以即时生效
• 短有效期 + refresh token 的权衡
• 黑名单（denylist）与白名单（allowlist）方案

JWT 无状态意味着服务端不保存 token 状态，签发后即使登出/改密/失窃，token 在过期前仍有效，撤销困难。两种主流方案：1）短有效期 + refresh token：access token 有效期很短（如 5~15 分钟），配合较长的 refresh token 换取新 access token；access token 被滥用或撤销的范围被限制在短窗口内，refresh token 可集中在服务端吊销（需存储）。这是"精简 + 可撤销"的均衡，但 refresh token 也成为新的攻击目标（需安全存储、轮换、防重放）。2）黑名单（denylist）：签发时记录 token 的 jti（唯一标识），撤销时把 jti 加入黑名单（如 Redis 缓存），校验时先查黑名单；由此可即时撤销，但引入服务端状态存储，削弱了"无状态"优势，且需处理黑名单过期与分布式一致性。权衡：追求无状态与扩展性用短有效期+refresh；追求即时撤销/敏感场景用黑名单或白名单（allowlist 只允许有效 token）。复杂系统常组合：短有效期 + 黑名单兜底（关键操作强制校验）。

核心是"无状态 vs 可撤销"的矛盾。答题需对比两种方案的成本与收益，并提及 refresh token 的存储与轮换安全。理解"jti 黑名单"和"短窗口"是落地点。

• RBAC：基于角色的权限分配
• ABAC：基于属性的属性化策略
• OAuth scope：令牌级的资源访问范围

RBAC（基于角色的访问控制）：把权限授予"角色"，再把用户分配给角色，用户通过角色获得权限；粗粒度、易管理、适合权限相对固定的组织，但角色爆炸和细粒度不足是其局限。ABAC（基于属性的访问控制）：基于用户、资源、环境、操作等属性组合（如"部门=财务 且 时间=工作时段"）做动态授权；细粒度、策略灵活，适合复杂/动态场景，但策略管理与性能成本更高。OAuth 作用域（scope）：不是独立的授权模型，而是 OAuth 2.0 令牌上附加的"权限范围"声明，表示客户端获得的资源访问范围（如 read、write、email），由授权服务器在签发令牌时授予，资源服务器据此校验；它属于"令牌级授权粒度"。工程上常组合：RBAC 定义用户角色→权限，ABAC 提供细粒度策略，OAuth scope 限定客户端在令牌上的访问范围。三者服务于"谁能访问什么、以何种粒度"的不同层次。

关键在于区分"角色、属性、作用域"三个维度。RBAC 角色化、ABAC 属性化、OAuth scope 令牌级。答题强调各自适用场景与组合使用。

• 会话固定：登录后轮换会话 ID
• 会话过期：绝对过期 + 空闲超时
• 会话刷新：续期机制与滥用防范

会话安全的核心是"确保会话 ID 无法被窃取、预测、复用，并在合理时机失效"。具体包括：1）会话固定防御——登录成功/权限提升后必须重新生成会话 ID（轮换），使攻击者预置的会话失效；2）会话过期——设置绝对过期时间（session 最长时间）与空闲超时（idle timeout，无操作多久后失效），敏感操作（支付、改密）要求更短窗口或二次认证；3）会话刷新（续期）——用户在活动时延长会话，但需注意"滚动续期"可能让会话无限存活，应限制最长绝对时长，并防止被攻击者利用续期机制无限延长；4）会话 ID 自身安全——强随机不可预测、通过 HttpOnly+Secure+SameSite cookie 传输、只在登录后生成、登出/超时显式销毁。此外可对高危操作做额外的会话验证（如重认证、设备指纹）。

会话安全五大要素：随机、轮换、过期、捎带安全属性、销毁。答题要覆盖"固定攻击、绝对+空闲过期、安全的刷新机制"并强调会话 ID 的全面保护。

• 加盐：防止彩虹表、避免相同密码相同哈希
• 慢哈希：bcrypt/scrypt/Argon2
• 强度策略：长度优先、泄露检查

密码存储必须加盐哈希，原因：1）加盐——为每个密码附加唯一随机盐后哈希，使相同密码产生不同哈希，防止彩虹表攻击（预计算哈希表）失效，也避免两个相同密码的哈希相同而被推断；2）慢哈希——使用 bcrypt/scrypt/Argon2 等慢哈希，抗 GPU/ASIC 暴力破解；3）绝不使用明文、可逆加密或 MD5/SHA-1 等快速哈希存储密码。密码强度策略：现代最佳实践是"长度优先于复杂度"（如至少 8~12 位，不强制无意义的复杂组合），并检查密码是否在已知泄露列表（如 Have I Been Pwned）中，拒绝弱/泄露密码；提供密码强度计引导用户；配合 MFA 与暴力破解防护（尝试限制、速率限制）。注意：强度策略要兼顾安全性与用户体验，避免强制变换导致用户用更弱密码。

"加盐 + 慢哈希"是存储的唯一正确姿势，强度策略"长度优先 + 泄露检查"。答题强调"盐是唯一的、慢哈希抗破解、禁用快速哈希"。

• MFA 的三种因素类型与原理
• 无密码认证：WebAuthn、通行密钥、魔法链接
• 现代最佳实践与风险

MFA（多因素认证）要求用户提供两种以上不同类型的认证因素：知识（something you know，如密码）、拥有（something you have，如手机/安全密钥）、固有（something you are，如生物特征）。它显著提升安全，因为攻击者即使获得密码也无法通过其它因素。现代实践推荐基于 WebAuthn/FIDO2 的安全密钥或设备（手机即密钥）作为强因素，TOTP 应用作为次选，基于短信的 OTP 因 SIM 劫持风险被降级。无密码认证（Passwordless）指不依赖密码的认证方式：WebAuthn 通行密钥（Passkey）——基于公钥密码学，私钥保存在设备安全硬件（TEE/安全芯片），服务器只存公钥，抗钓鱼、抗暴力破解；此外还有魔法链接（magic link，一次性链接）、OTP 等。现代趋势是"Passkey 优先"：无密码 + 强 MFA 特性（设备绑定），配合逐步淘汰密码。工程上需注意：通行密钥的账户恢复（设备丢失）、多设备同步、以及向后兼容（保留密码作为降级）。核心原则：基于公钥的 WebAuthn 优于共享密钥/TOTP，优于 SMS OTP。

答题要点：MFA 三因素、Passkey/WebAuthn 的公钥原理、SMS 风险、无密码的恢复与兼容。现代趋势是"公钥认证 + 设备绑定"。