用户身份验证真的很简单吗

发布时间：2022-02-15 12:54 所属栏目：53 来源：互联网

导读：你现在要建立一个系统。无论系统的功能如何，用户身份验证都是始终存在的一个功能。实现它看起来应该很简单只需拖动一些现成的身份验证模块，或使用一些基本选项(例如 Spring Security)对其进行配置，就完成了。是这样吗，不是的。上面说的是表面上的描述(

　　你现在要建立一个系统。无论系统的功能如何，用户身份验证都是始终存在的一个功能。实现它看起来应该很简单——只需“拖动”一些现成的身份验证模块，或使用一些基本选项(例如 Spring Security)对其进行配置，就完成了。

　　是这样吗，不是的。上面说的是表面上的描述(就比如要实现一个搜索引擎就一个输入框一个搜索按钮就行了??)，要做到正确的身份识别极其复杂。这不仅仅是登录表单 -> 检查用户名/密码 -> 设置 cookie，还有很多其他的问题需要考虑的：

　　Cookie 安全性
　　如何确保 cookie 不会泄漏或无法伪造。是否使用 cookie，或者使用 JWT 之类的无状态方法，使用 SameSite 宽松还是严格要求?

　　绑定IP
　　如果IP更改，将cookie绑定到IP并注销用户?

　　密码要求
　　最小长度、特殊字符?帮助选择密码的用户界面?

　　密码存储
　　在数据库中存储密码——bcrypt、scrypt、PBKDF2、SHA 多次迭代?

　　免密登录
　　允许存储在浏览器中，一般为“是”，但有些应用在发送前故意对其进行哈希处理，使其无法自动存储

　　账号样式
　　电子邮件、用户名与手机号——你需要用户名吗?是否允许更改电子邮件、手机号码?

　　限制登录错误数次
　　限制身份验证尝试 – 应该阻止多少次登录失败的帐户，管理员应该在多长时间内收到通知或至少记录锁定帐户?每个 IP、每个帐户的限制是这些的组合吗?

　　验证码
　　你需要验证码吗，哪一种，允许多少次尝试?刷新验证码是一种选择吗?

　　密码重置
　　密码重置令牌数据库表或与 HMAC 的过期链接?限制密码重置?

　　SSO
　　您的服务是否应该支持 LDAP/ActiveDirectory 身份验证(也许是)，它是否应该支持 SAML 2.0 或 OpenID Connect，如果支持，哪些?还是全部?是否应该只支持 SSO，而不是内部身份验证吗?

　　2FA – TOTP
　　实施整个 2FA(双因素认证) 流程，包括启用/禁用，或备份代码;在一段时间内不为特定设备请求 2FA来添加选项?根据某些组成员身份，配置 AD/LDAP 用户子集进行身份验证?

　　强制配置 2FA
　　通过管理员配置强制 2FA – 在启用全局选项后实现激活 2FA 的时间窗口?

　　一次性登录
　　通过链接登录 – 是否支持通过电子邮件发送一次性登录链接的选项?

　　XSS 保护
　　确保不存在 XSS 漏洞，特别是在登录页面上( XSS 可以窃取 cookie)

　　身份验证日志
　　专用身份验证日志 - 保留所有登录的历史记录，包括时间、IP、用户代理

　　强制注销
　　是否需要注销所需的已登录设备的功能。

　　允许移动设备保持登录状态
　　是否让移动设备保持登录状态——客户端应该存储什么?(当然不是密码明文)

　　保存用户登录地址
　　捕获用户的登录时区并将其存储在会话中以调整 UI 中的时间?

　　TLS 相互认证
　　如果我们需要支持使用私钥的令牌认证，我们应该启用 TLS 相互认证。证书库中应该有什么，Web 服务器是否支持每页双向 TLS 或者我们是否应该使用子域，如果有负载均衡器/反向代理，它是否支持以及如何转发证书详细信息?

　　是否需要激活步骤
　　需要激活账户还是让用户在注册后立即登录?需要后台人员批准账户?

　　初始密码设置
　　管理员创建的帐户的初始密码设置 - 生成初始密码并在首次登录时强制更改?不是生成密码并且从密码重置流程开始?

　　登录异常检测
　　如何检测登录异常，应该通过什么方式通知用户吗?是否依赖第三方工具(例如 SIEM)，还是内置此类功能?

　　身份验证是每个应用程序基本的功能。但很多开发人员或PM都不重视它。IT 世界很复杂，没有什么是简单的。发送电子邮件不简单，身份验证不简单，日志记录也不简单。处理字符串和日期并不简单，清理输入和输出也不简单。

　　我们在构建框架和工具，来帮助我们完成所有这些事情方面做得不够好。我们要积极对待这些问题，思考它们并做出最正确的方案。

（编辑：ASP站长网）