Authentication Security Events & Login History

认证安全事件日志记录登录成功/失败、MFA、凭证变更、恢复、会话撤销和风险动作，用于检测与调查；用户可见 Login History 是其最小化投影，不应与内部高保真安全审计日志混为一张表，也必须遵守隐私与保留策略。

#synthesis #evergreen #auth #observability

[!info] related notes

所属 MOC: 安全 MOC

Active Sessions: Active Sessions & Device Management

Risk: Suspicious Login & Risk-Based Authentication

Throttling: Authentication Throttling & Account Lockout

Recovery: Password Reset & Account Recovery

Revocation: Credential Change & Session Revocation

一句话关系

Security Event Log：

面向检测、调查、审计的内部事件流。

面向用户解释“最近发生了哪些登录/安全动作”的安全投影。

两者相关，但不是同一数据产品。

应记录什么事件

认证系统至少关注：

login success；
login failure；
success after repeated failures；
MFA success/failure；
recovery initiated/completed；
password change/reset；
email change；
MFA factor add/remove；
recovery code use；
Session revoke；
logout all devices；
trusted-device enrollment/revoke；
suspicious login / risk challenge；
account lock/throttle escalation。

OWASP 明确把 authentication successes/failures 与 Session security failures 视为重要日志事件。

Event Schema

建议使用稳定 event envelope：

event_id；
event_type；
occurred_at；
user_id/account_id；
session_id if applicable；
actor type；
source IP / ASN / coarse location；
device/browser summary；
auth methods；
risk result；
outcome；
reason code；
correlation/request id；
policy version。

避免把所有信息塞进 message string。

不记录 Secret

不要写入：

plaintext password；
raw Access/Refresh Token；
raw Session ID when avoidable；
raw reset token；
TOTP secret；
recovery code；
private key。

必要时只记录：

digest；
token/session identifier；
prefix/safe reference；
structured metadata。

Success 也要记录

只记录失败会丢失：

attacker 使用正确泄漏 credential 一次成功；
compromised Session 被正常使用；
suspicious new-device success。

因此登录成功本身也是安全事件。

用户页面可展示：

approximate time；
browser/app；
OS/device label；
coarse location / IP；
success/revoke state；
current session marker。

不要直接展示所有内部风控字段。

例如：

risk_score=0.83 rule=proxy_asn_cluster

可能帮助攻击者调试绕过规则。

Active Sessions：

当前仍 live/revocable 的认证状态。

历史事实，即使 Session 已经结束仍可以保留一段时间。

因此：

logout → Active Session disappears → historical login/logout events remain according to retention

详见 Active Sessions & Device Management。

Detection

事件流可以产生检测：

one account → many failed logins

one source → many accounts

new device

valid password
failed MFA

password reset → immediate API-key creation

这些是跨事件关系，不是单条 log message 能独立判断。

Notification

某些 Security Event 还应触发 user notification：

new login；
password changed；
email changed；
MFA changed；
recovery completed；
recovery code used；
suspicious login；
all sessions revoked。

通知应该引用事件，而不是另建一套不一致事实。

Immutability

安全日志通常希望：

application user cannot silently edit/delete history

可以使用：

append-only table；
restricted audit sink；
SIEM/log platform；
write-once retention controls。

但“不可变”仍要和隐私/法定删除/保留策略协调。

Privacy / Data Minimization

Security logs 可能包含：

IP；
device identifiers；
geolocation；
account identifiers。

它们可能属于个人数据。

所以必须定义：

retention duration；
access role；
encryption；
redaction；
export；
deletion/anonymization policy。

安全目的不是无限收集的许可证。

Clock / Ordering

分布式 Auth 系统要考虑：

UTC timestamp；
clock skew；
event id；
ordering/correlation；
retries/duplicate events。

用户页面不需要暴露这些复杂度，但内部检测系统需要稳定语义。

Reason Code

比自由文本更适合分析：

AUTHN_PASSWORD_INVALID AUTHN_MFA_REQUIRED AUTHN_MFA_INVALID AUTHN_SESSION_REVOKED AUTHN_RISK_STEP_UP AUTHN_RECOVERY_COMPLETED

这样 metrics / alert / investigation 更可靠。

学习检查

Security Event Log 与用户 Login History 为什么不是同一产品？
为什么 login success 也必须记录？
哪些 credential/secret 绝不能进入安全日志？
Active Sessions 与 Login History 在 logout 后有什么不同？
为什么内部 risk rule 不应原样展示给用户？
Security Event Log 为什么同时涉及安全和隐私治理？
设计一个 password reset → revoke sessions → new login 的事件序列。