security-ux

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Build security interfaces that earn user trust through clarity, not intimidation. The goal is to make users feel safe and in control, not punished for security requirements.

Consult the authentication and account recovery reference for sign-in, MFA, session expiry, password UX, and recovery-stack guidance. Consult the permissions and roles UX reference for role editors, request-access flows, access-denied recovery, and risky permission changes. Consult the interface honesty reference for assertive UX language, honest progress and consent copy, and trust-preserving product behavior. Consult the error recovery reference for what happens after security-related failures.

打造通过清晰性而非威慑感赢得用户信任的安全界面。目标是让用户感到安全且掌控自如，而非因安全要求觉得自己被惩罚。

有关登录、MFA、会话过期、密码UX和恢复栈的指导，请参阅身份验证与账户恢复参考文档。有关角色编辑器、访问申请流程、访问被拒后的恢复、高风险权限变更的内容，请参阅权限与角色UX参考文档。有关笃定的UX文案、诚实的进度与同意提示、维护信任的产品行为的内容，请参阅界面诚实性参考文档。有关安全相关故障后处理方式的内容，请参阅错误恢复参考文档。

MANDATORY PREPARATION

强制性准备工作

Users start this workflow with

/security-ux

. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: what threat model the product faces, what security features are already implemented, and where users currently feel confused or anxious about security.

用户通过

/security-ux

启动此工作流。此技能激活后，加载$frontend-design——它包含设计原则、反模式以及上下文收集协议。在继续操作前请遵循该协议——如果尚无设计上下文，你必须先加载$setup。此外还需收集：产品面临的威胁模型、已实现的安全功能，以及用户当前对安全方面感到困惑或焦虑的点。

Assess Security UX Needs

评估安全UX需求

Identify where security and user experience intersect:

Authentication flow: How do users sign in? Is MFA required or optional? How painful is the current flow?
Password experience: Are requirements reasonable? Is there guidance on creating strong passwords?
Trust signals: Does the interface communicate security clearly (HTTPS indicators, verified badges, encryption notes)?
Recovery paths: What happens when users lose access? Is recovery secure but not impossible?
Breach and anomaly response: How does the product notify users of suspicious activity or data breaches?
Permission and consent: Are users making informed decisions about what they share?

明确安全与用户体验的交叉点：

身份验证流程：用户如何登录？MFA是必填还是选填？当前流程的使用成本有多高？
密码体验：密码要求是否合理？是否提供创建强密码的指导？
信任信号：界面是否清晰传达了安全性（HTTPS标识、已验证徽章、加密说明）？
恢复路径：用户失去访问权限时会发生什么？恢复流程是否安全但并非遥不可及？
数据泄露与异常响应：产品如何通知用户可疑活动或数据泄露事件？
权限与同意：用户是否能就自己分享的内容做出知情决策？

Security UX Dimensions

安全UX维度

Authentication

身份验证

Sign-in flow:

Keep the sign-in form minimal: email and password, or social auth options
Show/hide password toggle so users can verify their input
Do not clear the email field on failed attempts
Distinguish "email not found" from "wrong password" only if it does not aid account enumeration attacks
Rate-limit failed attempts and show a clear cooldown message

Multi-factor authentication (MFA):

Offer multiple MFA methods (TOTP app, SMS, hardware key, backup codes)
Default to the most secure method the user has set up
Provide clear setup instructions with visual guides
Allow naming devices so users know what they are approving
Show recovery codes during setup and prompt users to save them
Do not make MFA feel like a punishment; frame it as protection

Session management:

Show active sessions in settings with device and location info
Allow users to revoke individual sessions
Notify users of new sign-ins from unfamiliar devices or locations
Use "Remember this device" sparingly and explain what it means

登录流程：

保持登录表单简洁：仅邮箱和密码，或提供第三方登录选项
提供显示/隐藏密码的切换按钮，方便用户验证输入
登录失败时不要清空邮箱字段
仅在不会助长账户枚举攻击的情况下，才区分「邮箱未注册」和「密码错误」的提示
对失败尝试进行速率限制，并显示清晰的冷却提示

多因素认证（MFA）：

提供多种MFA方式（TOTP应用、短信、硬件密钥、备用码）
默认使用用户已设置的最安全方式
提供清晰的设置说明及可视化指南
允许为设备命名，让用户清楚自己正在批准的设备
设置过程中显示恢复码，并提示用户保存
不要让MFA看起来像一种惩罚；将其定位为保护措施

会话管理：

在设置中显示活跃会话，并附带设备和位置信息
允许用户撤销单个会话
当有来自陌生设备或位置的新登录时，通知用户
谨慎使用「记住此设备」选项，并解释其含义

Password UX

密码UX

Requirements that don't frustrate:

Minimum length (12+ characters) matters more than complexity rules
Explain why: "Longer passwords are harder to guess"
Show a strength meter as the user types, not just on blur
Allow passphrases ("correct horse battery staple")
Do not require arbitrary character mixing (one uppercase, one symbol) if length is sufficient
Never expire passwords arbitrarily; it encourages weak patterns

Password creation guidance:

Suggest a generated password or passphrase
Show requirements before the user starts typing, not after they fail
Use inline validation for length, not a popup on submit

不会造成困扰的要求：

最小长度（12+字符）比复杂度规则更重要
解释原因：「更长的密码更难被破解」
在用户输入时实时显示密码强度计，而非仅在失焦时显示
允许使用密码短语（如「correct horse battery staple」）
如果密码长度足够，不要强制要求任意的字符组合（如一个大写字母、一个符号）
绝不要随意强制密码过期；这会催生弱密码模式

密码创建指导：

建议使用生成的密码或密码短语
在用户开始输入前就显示密码要求，而非等他们输入失败后才提示
对长度进行内联验证，不要在提交时弹出提示

Trust Indicators

信任标识

Visual signals:

Show lock icons near sensitive fields (payment, passwords)
Display security badges or certifications where relevant (PCI DSS, SOC 2)
Use HTTPS and show the secure connection indicator in the browser
Explain encryption in plain language ("Your data is encrypted") not jargon

Transparency:

Explain what data is collected and why before asking for it
Show privacy policy links near consent checkboxes
Use plain language for security settings, not enterprise terminology
Allow users to review and export their data

视觉信号：

在敏感字段（支付、密码）附近显示锁形图标
在相关位置显示安全徽章或认证（PCI DSS、SOC 2）
使用HTTPS，并在浏览器中显示安全连接标识
用平实的语言解释加密（「你的数据已加密」），而非使用术语

透明度：

在收集数据前，解释收集了什么数据以及原因
在同意复选框附近显示隐私政策链接
安全设置使用平实语言，而非企业级术语
允许用户查看和导出自己的数据

Account Recovery

账户恢复

Secure but reachable:

Offer multiple recovery methods (email, phone, backup codes, trusted contacts)
Verify identity before allowing recovery; do not skip steps for convenience
Send notifications to existing contact methods when recovery is initiated
Time-limit recovery links and codes
Require re-authentication before sensitive actions after recovery

Recovery UX:

Guide users step-by-step through recovery
Explain what will happen at each step
Provide clear alternatives if one recovery method fails
Do not trap users in loops where recovery requires the very thing they lost

安全但可及：

提供多种恢复方式（邮箱、手机、备用码、可信联系人）
允许恢复前先验证身份；不要为了方便跳过步骤
当发起账户恢复时，向已有的联系方式发送通知
恢复链接和验证码设置有效期
恢复后执行敏感操作前，要求重新验证身份

恢复UX：

逐步引导用户完成恢复流程
解释每一步会发生什么
如果一种恢复方式失败，提供清晰的替代方案
不要让用户陷入死循环：比如恢复账户需要用到他们已经丢失的东西

Breach and Anomaly Notifications

数据泄露与异常通知

Breach notifications:

Notify users promptly when their account may be compromised
Be specific about what happened and what data was affected
Provide clear, immediate actions: change password, review sessions, enable MFA
Do not bury breach notices in marketing emails

Anomaly alerts:

Notify users of unusual sign-in attempts with device and location
Allow users to approve or block the attempt directly from the notification
Provide a "This was me" / "This was not me" choice, not just an informational alert
Do not cry wolf; too many false positives train users to ignore alerts

数据泄露通知：

当用户账户可能被入侵时，及时通知用户
明确说明发生了什么以及哪些数据受到影响
提供清晰、可立即执行的操作：修改密码、查看会话、开启MFA
不要把数据泄露通知藏在营销邮件里

异常告警：

向用户通知异常登录尝试，并附带设备和位置信息
允许用户直接从通知中批准或阻止该登录尝试
提供「是我本人」/「不是我」的选项，而非仅发送信息性告警
不要「狼来了」；太多误报会让用户养成忽略告警的习惯

Consent and Permissions

同意与权限

Informed consent:

Explain what the user is agreeing to in plain language, not legal jargon
Use progressive disclosure: show the summary first, allow expanding for details
Separate consent for different purposes (marketing vs. functionality)
Allow users to revoke consent as easily as they gave it
Do not pre-check consent boxes

知情同意：

用平实的语言解释用户同意的内容，而非法律术语
使用渐进式披露：先显示摘要，允许用户展开查看详情
对不同用途的同意进行拆分（营销用途 vs 功能用途）
允许用户像当初给予同意一样轻松地撤销同意
不要预先勾选同意复选框

Accessibility

无障碍访问

Ensure MFA code inputs are large and easy to type on mobile
Provide time remaining for TOTP codes visually and for screen readers
Use
```
aria-live
```
for security alerts and notifications
Ensure trust indicators are perceivable without color alone
Make recovery flows fully keyboard-navigable

确保MFA验证码输入框足够大，在移动端易于输入
以视觉形式和屏幕阅读器可读的方式，提供TOTP验证码的剩余有效时间
安全告警和通知使用
```
aria-live
```
属性
确保信任标识不依赖颜色也能被感知
确保恢复流程完全支持键盘导航

Anti-Patterns

反模式

Security theater: Visual lock icons on non-sensitive pages that do not actually protect anything
Arbitrary password complexity: Requiring symbols and numbers but allowing short passwords
Blaming users for breaches: "You should have enabled MFA" instead of "We are helping you secure your account"
Hiding security settings: MFA and recovery options buried in menus users never find
False urgency: "Your account will be deleted in 24 hours" for routine verification
No recovery path: Account permanently locked because the user lost their phone
Jargon-heavy security copy: "Enable 2FA via TOTP" instead of "Add an authenticator app for extra security"
Silent breaches: Not notifying users when their data is compromised
Pre-checked consent boxes: Violates trust and often regulations
Inconsistent security posture: Strong MFA but weak password recovery bypasses it

安全剧场：在非敏感页面显示锁形图标，但实际上没有任何保护作用
任意的密码复杂度要求：要求符号和数字，但允许短密码
数据泄露后指责用户：说「你本应该开启MFA」，而非「我们正在帮你保障账户安全」
隐藏安全设置：MFA和恢复选项被埋在用户永远找不到的菜单里
虚假紧迫感：为了常规验证说「你的账户将在24小时内被删除」
无恢复路径：因为用户丢了手机，账户就被永久锁定
满是术语的安全文案：写「通过TOTP开启2FA」，而非「添加身份验证器应用以增强安全性」
静默的数据泄露：用户数据被入侵时不通知用户
预先勾选的同意复选框：违背信任，且通常违反法规
不一致的安全态势：MFA很强，但薄弱的密码恢复会绕过它