今年年初，美国征信巨头 TransUnion 的南非公司遭巴西黑客团伙 N4aughtysecTU 袭击，约 90% 南非公民的征信数据泄露。而让南非沦为“黑客乐园”的，恰是“密码”本身。

犯罪团伙声称，他们最终入侵账户时使用的密码为“Password”。此前，NordVPN 就在一份报告中将“password”列为 2021 年全球五大最常用密码之一，称目前的暴力手段在 1 秒内就能将其破解。FIDO 联盟也认为，密码身份验证成为现今最大的安全问题之一。

那么，我们只能束手无策了吗？

01

GitHub、Google 试水新方法

5 月 4 日，GitHub 宣布，到 2023 年底，所有在 GitHub.com 上传代码的用户都需要启用一种或多种形式的双因素身份认证，才能够继续使用该平台。

GitHub 对双因素认证的介绍

双因素身份认证（Two-Factor Authentication，2FA）是一种安全验证方式，也称“两步验证”。区别于传统的密码验证，它要求提供两个认证因素才能完成身份认证。

而我们常听到的多因素身份认证（Multi-Factor Authentication，MFA），则是进阶版的 2FA。用户需要提供两个或两个以上的认证因素才能访问某个资源，如访问应用程序、在线账户或 VPN 等。

常见的认证因素大致可以分为以下三种类型：

你有遇到过使用账密登录某个应用时，系统还要求填写短信验证码的情况吗？其实，这种一次性密码 （One-Time Password，OTP）就是 MFA 的认证因素之一。

不少人可能会怀疑，这样的办法真的奏效吗？

其实，早从去年开始，Google 已率先推行多因素认证，并卓有成效。今年 2 月，Google 称默认开启双因素认证的 1.5 亿测试用户群中，被泄露的情况减少了 50%。

02

你的企业，用得上多因素认证吗？

场景一：开发者使用 MFA 保护数据安全

某开源网站为所有开发者默认开启多因素认证，避免了其资源库被劫持、数据被盗和项目被破坏。

开源项目对个人和企业都是宝贵的资源。而对软件行业来说，供应链的最上游就是开发者，第一步就是要保证开发者的身份认证安全。

实际上，Authing 就非常注重开发者用户体验，持续深耕开发者友好。开发团队可在平台上对所需开发的应用进行集成，无需重复构建、购买身份管理方案。

场景二：高科技行业部署 MFA 保障交易安全

某高新企业内部使用了多套系统，且各个账号体系对于密码的安全等级需求也不一致。员工在不同系统切换时，需要多次进行身份验证，如果验证不成功，还得找 IT 部门更换密码，造成体验不佳，极大地影响了工作效率。

部署 MFA 后，可以在登录严格权限的程序或网络之前验证用户身份，配合单点登录（SSO）实现无缝访问多个应用程序，提高了员工和 IT 的生产力。

场景三：游戏行业开启基于云的 MFA 赢得用户信赖

某游戏平台为其 200 多万玩家开启多因素认证，以防止他们的账号和游戏内财产被恶意接管，提升了用户信赖度和站内安全。

游戏、社交媒体甚至是流媒体越来越成为人们生活不可分割的部分，但日渐庞大的用户数量可能让企业对部署多因素认证望而却步。

此时，基于云的 MFA 能大大减少企业在方案部署、人力资源、硬件、软件各方面的耗费。Authing 这种云原生的 SaaS 厂商还支持分钟级别的弹性扩容能力，能够应对外部快速变化的诉求。

当然，除了上述场景外，各行各业都可以依靠 MFA 满足移动化办公的安全需求。如何在有限资源的条件下，确保产业链各类角色成员都能高效、安全地访问各类应用系统及办公资源，是 IT 管理部门的重要任务。

比如，员工在异地出差时，在公共场所办公、登录公司内网时，或使用了非加密的 Wifi 网络登录，如何证明是本人行为？毕竟，不法分子只需要一款特殊设备，就通过 USB 接口读取用户目标电脑内存中的信息。此时 MFA 就会提示他们验证其他信息，比如邮箱、短信、地理位置等。

比如，员工在设置密码时，为了省事好记，将密码设置为“123456”，“helloworld”，“welcome”等傻瓜密码。然而，绝大多数安全漏洞都是由凭据问题引起的。此时，MFA 可以在密码之外多增加一层安全保护，确保企业数据安全。

比如，在一些安全性要求较严格的企业，IT 部门会要求员工设置更为复杂的密码，但是越复杂越难记，导致 IT 部门会陷入频繁为员工重置密码的困境。使用了 MFA 后，可高效保护环境、员工以及他们所使用的设备，而无需繁琐的重置或复杂的密码策略，让 IT 人员有时间去做更为战略性、核心的业务。

MFA 提高了安全性，即使一个凭据遭到入侵，未经授权的用户也无法满足第二个身份验证要求，并且也无法访问目标用户的身份空间、计算机设备、网络或数据库。

03

更高效、完备、灵活的 Authing 多因素认证

“我只是想在 GitHub 上交个作业，添加强制性 2FA 是一个额外的负担。”有用户抱怨道。

其实，多因素面对的争议并非无解，自适应 MFA 就可以提供更加灵活和智能的验证策略。

自适应 MFA 也指基于风险的认证，能够根据当前安全状况选择应用不同的认证方式，在保障安全的同时也优化用户体验。

举个例子，假设你晚上九点（非工作时间）在咖啡店（非办公地点）连接店里的 Wifi （非专用网络）登录公司的系统，那么可能会被要求额外提供 OTP。如果你明天一早在办公室尝试登录，可能只需要账号和密码就行。

Authing 多因素认证就支持调取不同的认证因素，结合账密为用户资源提供更高的安全保护。

• 基于短信验证码的 MFA

• 基于邮件验证码的 MFA

• 基于时间戳算法的一次性密码的 MFA

• 基于人脸识别的 MFA

其中，基于时间戳的一次性密码（Time-based One-time Password，TOTP）是验证应用程序生成的代码，可能几分钟就变动一次，只有验证程序和你试图连接的账户服务器才知道其生成算法。

这种基于云的多因素认证方式，不需要依赖网络和运营商信号，更能有效验证操作的合法性，这也是 GitHub 强烈推荐的认证方式之一。

而一项操作具体有多大风险，又是怎么计算出来的呢？

在用户进行认证流程时，Authing 多因素认证会对当前登录的用户生成多种关键要素，包括：

用户属性: 如用户名、密码、用户身份等用户自身的属性和信息。

位置感知: 位置感知分为虚拟位置（IP 地址）和物理位置（国家、地区等）。

请求来源: 对当前用户的请求来源进行判断，如硬件设备信息、用户当前所在的系统等。

生物识别: 对使用用户的生物信息进行识别，如人脸识别。

行为分析: 是否来自常用的登录地点、是否多次输入错误密码、用户之前的操作记录等一系列用户行为。

Authing 能做的不只是 “多”，还能够“准” 。这些关键因素共同组成了“上下文”，也就是判断是否需要用户提供多个认证因素的依据。

除了实现环境风险自适应、支持在用户池级别自定义配置 MFA 外，Authing 多因素认证还具备以下核心功能：

• Authing 通过多种认证方式保障业务安全。

• 自定义认证流程，一键开启，操作简单。

• 支持设备环境数据上报，多维度分析安全级别。

• 同时适用于应用内权限控制场景。

• 默认集成于通用登录组件（Guard）。

• 管理用户数据，查询行为日志。

提供 SDK 与开放接口，助力开发者快速调用相关能力，并构建自定义的用户管理页面。

如果想配置这样高效、完备、灵活的多因素认证，步骤会很繁琐吗？

当然不是。

Authing 多因素认证仅需调用一个方法，就可以唤起 MFA 认证组件，拿到认证结果，完成认证流程：

• 一键开启/关闭 MFA。

• 一键启用默认安全策略，不必理解策略配置，也能使应用安全性得到很大提高。

• 预设十几种重要且常用的策略命中条件，即选即生效，不是工程师也能使用。

• 有兴趣的开发者可以通过 SDK 接入 MFA，体验认证流程的定制化开发。详情可见文档：

https://docs.authing.cn/v2/guides/authentication/mfa/mfa-sdk.html

点击此处了解更多行业身份管理

「解决方案」以及「最佳实践案例」