身份认证，作为应用系统的大门，其重要性不言而喻，从技术视角来看，各类认证类协议提供了一体化解决方案，如oauth、sso等，但是从产品设计\安全设计视角，如果去做一套认证方案，这个目前研究的师傅不是很多。而常见的认证类漏洞，除了协议本身的漏洞、认证的组件漏洞外。最常见的是密码测试型，包括暴力破解、密码喷洒、凭据填充、以及密码猜测，这类我个人总结为密码测试型，而在我看来，协议类与组件类很难完全消除风险，因为可能会有0day，但是密码测试类是完全可以规避的，这里我简单说一些在开发过程中常见防御措施供各位架构师参考。

多因素认证

多因素认证（MFA）是防御大多数与密码相关的攻击的最佳手段，包括凭证填充和密码喷洒。

但是为了平衡安全性和可用性，可以结合其他技术实施MFA，即仅在特定情况下需要第二因素，例如在以下情况下怀疑登录尝试可能会存在安全风险：——但是具体的分析过程还需要结合后端分析逻辑落地，这里就不再详细描述

• 来自新的浏览器/设备或IP地址的登录。
• 来自异常的国家或地区。
• 来自被认为不可信的特定国家。
• 出现在已知黑名单上的IP地址。
• 尝试登录多个账户的IP地址。
• 通过脚本自动化登录。

如果是企业级应用程序，可以将已知可信的IP范围添加到可信IP列表（即白名单），在保障供应链安全的前提下，可以不用双因素。

补充防御措施

在无法实施MFA的情况下，有许多替代防御措施可以降低认证系统的风险。单独使用这些措施没有MFA有效，但如果以分层方法实施多个防御措施，也能够尽可能降低认证类风险。

当应用程序具有多个用户角色时，可能适合为不同角色实施不同的防御措施。例如，如果不能为所有用户强制执行MFA，但需要要求管理员账号进行双因素认证。

PIN码和安全问题

除了要求用户在身份验证时输入密码外，还可以提示他们提供其他安全信息，例如：

• PIN码
• 安全问题

验证码

为了平衡体验问题，可以在几次验证失败后自动弹出验证码

IP封禁

多次验证失败后可以封禁源IP，这个可以和SOC结合

设备指纹

除了IP地址外，还有许多不同的因素可以用来尝试识别设备。其中一些可以通过服务器从HTTP头文件（特别是“User-Agent”头文件）中被动获取，包括：

• 操作系统
• 浏览器
• 语言

使用JavaScript可以访问更多信息，例如：

• 屏幕分辨率
• 安装的字体
• 安装的浏览器插件

使用这些不同的属性，可以创建设备的指纹。然后可以将此指纹与尝试登录账户的任何浏览器进行匹配，如果指纹不匹配，则可以提示用户进行额外的身份验证。但是这个尽量用于APP的验证中，浏览器误报太多

可以使用fingerprintjs2 JavaScript库执行客户端指纹识别。

用户名不可预测

凭证填充攻击不仅依赖于在多个站点之间重用密码，还依赖于重用用户名。大量网站使用电子邮件地址作为用户名，主要是因为大多数用户将使用单一电子邮件地址用于他们所有的账户。可以在用户在注册网站时创建自己的用户名，这使得攻击者更难获得用于凭证填充的有效用户名和密码对，因为许多可用的凭证列表只包括电子邮件地址。为用户提供生成的用户名可以提供更高程度的保护（因为用户可能在大多数网站上选择相同的用户名），但对用户友好。此外，需要谨慎确保生成的用户名不可预测（例如，基于用户的全名或顺序数