今年年初,美国征信巨头 TransUnion 的南非公司遭巴西黑客团伙 N4aughtysecTU 袭击,约 90% 南非公民的征信数据泄露。而让南非沦为“黑客乐园”的,恰是“密码”本身。
犯罪团伙声称,他们最终入侵账户时使用的密码为“Password”。此前,NordVPN 就在一份报告中将“password”列为 2021 年全球五大最常用密码之一,称目前的暴力手段在 1 秒内就能将其破解。FIDO 联盟也认为,密码身份验证成为现今最大的安全问题之一。
那么,我们只能束手无策了吗?
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%。
某开源网站为所有开发者默认开启多因素认证,避免了其资源库被劫持、数据被盗和项目被破坏。
开源项目对个人和企业都是宝贵的资源。而对软件行业来说,供应链的最上游就是开发者,第一步就是要保证开发者的身份认证安全。
实际上,Authing 就非常注重开发者用户体验,持续深耕开发者友好。开发团队可在平台上对所需开发的应用进行集成,无需重复构建、购买身份管理方案。
某高新企业内部使用了多套系统,且各个账号体系对于密码的安全等级需求也不一致。员工在不同系统切换时,需要多次进行身份验证,如果验证不成功,还得找 IT 部门更换密码,造成体验不佳,极大地影响了工作效率。
部署 MFA 后,可以在登录严格权限的程序或网络之前验证用户身份,配合单点登录(SSO)实现无缝访问多个应用程序,提高了员工和 IT 的生产力。
某游戏平台为其 200 多万玩家开启多因素认证,以防止他们的账号和游戏内财产被恶意接管,提升了用户信赖度和站内安全。
游戏、社交媒体甚至是流媒体越来越成为人们生活不可分割的部分,但日渐庞大的用户数量可能让企业对部署多因素认证望而却步。
此时,基于云的 MFA 能大大减少企业在方案部署、人力资源、硬件、软件各方面的耗费。Authing 这种云原生的 SaaS 厂商还支持分钟级别的弹性扩容能力,能够应对外部快速变化的诉求。
当然,除了上述场景外,各行各业都可以依靠 MFA 满足移动化办公的安全需求。如何在有限资源的条件下,确保产业链各类角色成员都能高效、安全地访问各类应用系统及办公资源,是 IT 管理部门的重要任务。
比如,员工在异地出差时,在公共场所办公、登录公司内网时,或使用了非加密的 Wifi 网络登录,如何证明是本人行为?毕竟,不法分子只需要一款特殊设备,就通过 USB 接口读取用户目标电脑内存中的信息。此时 MFA 就会提示他们验证其他信息,比如邮箱、短信、地理位置等。
比如,员工在设置密码时,为了省事好记,将密码设置为“123456”,“helloworld”,“welcome”等傻瓜密码。然而,绝大多数安全漏洞都是由凭据问题引起的。此时,MFA 可以在密码之外多增加一层安全保护,确保企业数据安全。
比如,在一些安全性要求较严格的企业,IT 部门会要求员工设置更为复杂的密码,但是越复杂越难记,导致 IT 部门会陷入频繁为员工重置密码的困境。使用了 MFA 后,可高效保护环境、员工以及他们所使用的设备,而无需繁琐的重置或复杂的密码策略,让 IT 人员有时间去做更为战略性、核心的业务。
MFA 提高了安全性,即使一个凭据遭到入侵,未经授权的用户也无法满足第二个身份验证要求,并且也无法访问目标用户的身份空间、计算机设备、网络或数据库。
“我只是想在 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
点击此处了解更多行业身份管理
「解决方案」以及「最佳实践案例」