关于 security-ux
security-ux 是用于设计清晰、令人安心的安全界面的技能,避免让安全要求显得具有威慑性。内容涵盖身份验证、账户恢复、信任提示、警报和知情同意,并关注用户掌控感与无障碍流程。
主要功能
- 01检查身份验证与 MFA 流程
- 02改进密码和恢复指引
- 03清晰呈现信任提示与通知
- 04设计可执行的安全警报
- 05明确同意与权限说明
- 06检查无障碍和失败恢复
适用场景
- 01简化登录与 MFA 设置
- 02引导用户恢复账户
- 03说明可疑登录警报
- 04让数据共享同意易于理解
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ aladicf/ better-react-web-ui --skill security-ux安装后在 Claude Code 中输入/security-ux确认已加载。
详细介绍
构建清晰而非令人生畏的安全界面,赢得用户信任。目标是让用户感到安全并能掌控一切,而不是觉得自己因安全要求受到了惩罚。
有关登录、多因素身份验证(MFA)、会话过期、密码体验和账户恢复流程的指导,请参阅身份验证和账户恢复参考文档。 有关角色编辑器、申请访问流程、拒绝访问后的恢复,以及高风险权限变更的指导,请参阅权限和角色用户体验参考文档。 有关果断的用户体验文案、诚实的进度与同意文案,以及维护信任的产品行为,请参阅界面诚信参考文档。 有关安全相关故障后的处理方式,请参阅错误恢复参考文档。
必须完成的准备工作
阅读 frontend-design,并遵循其中的上下文收集协议。复用已有上下文,仅针对重要的信息缺口提问。此外,还需了解:产品面临怎样的威胁模型、已经实现了哪些安全功能,以及用户目前在哪些安全问题上感到困惑或焦虑。
评估安全体验需求
找出安全与用户体验的交汇点:
- 身份验证流程:用户如何登录?MFA 是必需还是可选?当前流程有多繁琐?
- 密码体验:要求是否合理?是否提供创建强密码的指导?
- 信任信号:界面是否清楚地传达安全信息(HTTPS 指示、已验证徽章、加密说明)?
- 恢复途径:用户失去访问权限时会发生什么?恢复过程是否既安全又可行?
- 泄露和异常响应:产品如何通知用户可疑活动或数据泄露?
- 权限和同意:用户是否充分了解自己正在分享的内容,并据此作出决定?
安全体验维度
身份验证
登录流程:
- 登录表单应保持简洁:电子邮件和密码,或社交账号身份验证选项
- 提供显示/隐藏密码切换功能,让用户核对输入内容
- 登录失败时不要清空电子邮件字段
- 只有在不会助长账户枚举攻击的情况下,才区分“未找到电子邮件地址”和“密码错误”
- 对失败尝试进行速率限制,并清楚说明冷却时间
多因素身份验证(MFA):
- 提供多种 MFA 方式(TOTP 应用、SMS、硬件密钥、备用代码)
- 默认使用用户已设置的最安全方式
- 提供清晰的设置说明和可视化指南
- 允许用户为设备命名,让他们知道自己正在批准哪台设备
- 在设置过程中显示恢复代码,并提示用户保存
- 不要让 MFA 显得像惩罚;应将其描述为一种保护措施
会话管理:
- 在设置中显示活动会话及其设备和位置信息
- 允许用户撤销单个会话
- 对来自陌生设备或位置的新登录向用户发送通知
- 谨慎使用“记住此设备”,并说明其含义
密码体验
避免令人沮丧的要求:
- 最小长度(12 个或更多字符)比复杂性规则更重要
- 说明原因:“密码越长,越难猜”
- 在用户输入时显示强度指示器,而不只是失焦后显示
- 允许使用密码短语(“correct horse battery staple”)
- 如果长度足够,就不要强制要求任意的字符组合(一个大写字母、一个符号)
- 切勿随意让密码过期;这会助长薄弱的密码习惯
密码创建指导:
- 建议使用生成的密码或密码短语
- 在用户开始输入前显示要求,而不是等输入不符合要求后才显示
- 对长度进行内联验证,不要等到提交时才弹出提示
信任指标
视觉信号:
- 在敏感字段(付款、密码)旁显示锁图标
- 在适当的位置显示安全徽章或认证标识(PCI DSS、SOC 2)
- 使用 HTTPS,并在浏览器中显示安全连接指示标识
- 用通俗的语言解释加密(“您的数据已加密”),而不是使用术语
透明度:
- 在索取数据前说明会收集哪些数据以及原因
- 在同意复选框附近显示隐私政策链接
- 用通俗的语言说明安全设置,不使用企业术语
- 允许用户查看并导出自己的数据
账户恢复
安全且可用:
- 提供多种恢复方式(电子邮件、电话、备用代码、可信联系人)
- 在允许恢复前验证身份;不要为了方便而跳过步骤
- 启动恢复时,向现有联系方式发送通知
- 为恢复链接和代码设置有效期限
- 恢复后执行敏感操作前,要求重新进行身份验证
恢复体验:
- 按步骤引导用户完成恢复
- 说明每一步将会发生什么
- 如果某种恢复方式失败,提供明确的替代方案
- 不要让用户陷入循环,例如要求用户通过已丢失的内容进行恢复
泄露和异常通知
泄露通知:
- 账户可能遭到入侵时,及时通知用户
- 具体说明发生了什么以及哪些数据受到影响
- 提供明确且可立即执行的操作:更改密码、检查会话、启用 MFA
- 不要把泄露通知埋在营销邮件中
异常警报:
- 有异常登录尝试时,向用户提供设备和位置等信息
- 允许用户直接通过通知批准或拦截此次尝试
- 提供“这是我本人操作”/“这不是我本人操作”选项,而不只是发送信息性警报
- 不要频繁误报;过多的误报会让用户逐渐忽视警报
同意和权限
知情同意:
- 用通俗的语言说明用户同意的内容,而不是使用法律术语
- 采用渐进式披露:先显示摘要,并允许展开查看详情
- 将不同用途的同意分开(营销与功能)
- 允许用户像给予同意一样轻松地撤回同意
- 不要预先勾选同意复选框
无障碍设计
- 确保 MFA 验证码输入框尺寸足够大、易于输入,并兼容浏览器自动填充和一次性验证码功能
- 以视觉方式和屏幕阅读器可识别的方式显示 TOTP 代码的剩余有效时间
- 对安全警报和通知使用
aria-live - 确保仅凭颜色以外的方式也能感知信任指标
- 确保恢复流程可通过键盘完整操作
反面模式
- 安全作秀:在实际上没有任何保护作用的非敏感页面上显示锁图标
- 武断的密码复杂度要求:要求包含符号和数字,却允许使用很短的密码
- 将泄露归咎于用户:说“您本应启用 MFA”,而不是“我们会帮助您保护账户安全”
- 隐藏安全设置:将 MFA 和恢复选项埋在用户根本找不到的菜单中
- 虚假紧迫感:对于常规验证,声称“您的账户将在 24 小时后被删除”
- 没有恢复途径:用户丢失手机后,账户被永久锁定
- 充斥术语的安全文案:说“通过 TOTP 启用 2FA”,而不是“添加身份验证器应用以增强安全性”
- 对泄露保持沉默:数据遭到泄露时不通知用户
- 预先勾选同意复选框:损害信任,且往往违反法规
- 安全措施不一致:MFA 很强,但薄弱的密码恢复流程可以绕过它
验证安全体验质量
发布前:
- 登录流程简洁且宽容
- MFA 设置清晰,并提供多种方式
- 密码要求优先考虑长度,而非随意设定的复杂性
- 信任指标诚实且具体
- 恢复途径既安全又易于使用
- 泄露和异常通知及时且可采取行动
- 用户同意应基于充分知情、细化到具体事项,并且易于撤销
- 安全相关文案使用通俗语言,而非行话
- 警报应足够具体,便于采取行动,但也不能过于频繁,以免沦为噪声
- 界面应让用户感到安全且能掌控局面,而非受到惩罚
评论
支持 Markdown