关于安全:技术人员需要了解的手机验证码登录风险

7次阅读

共计 4183 个字符,预计需要花费 11 分钟才能阅读完成。

手机验证码登录是一种常见的利用登录形式,简略不便,不必记忆明码,市面上能见到的 APP 根本都反对这种登录形式,很多利用还把登录和注册集成到了一起,注册 + 登录零打碎敲,给用户省去了很多麻烦,颇有一机在手、天下我有的感觉。

登录原理

手机验证码登录的原理很简略,对于一个失常的登录流程,看下边这张图就够了:

理论利用中会存在一些收不到验证码的状况,可能的起因如下:

  • 在手机端,短信被某些软件认为是垃圾信息而被拦挡或者删除,或者因为手机卡欠费导致收不到短信。
  • 在利用服务端,因为程序谬误,或者平安控制策略导致局部短信发送失败。
  • 在短信平台或者电信运营商零碎,因为黑名单、关键字、流量管制,或者其它某些技术起因导致发送失败。

针对收不到短信的问题,零碎中会减少重发验证码性能,如果多次重发还收不到,零碎能够反对上行短信或者语音验证码的形式,这两种形式都是短信验证码的变种。

  • 上行短信是让用户将零碎提前生成好的若干字符发送到零碎指定的短信号码,据此能够验证用户领有指定手机的控制权,从而也就认证了用户的身份。

  • 语音验证码能够让用户发动,也能够在零碎收到短信发送未胜利的回执时被动推送,用户手机会收到一个主动语音通话,其中蕴含登录所需的验证码。

平安危险和应答策略

手机验证码的平安危险次要是被歹意利用和窃取。

因为手机验证码的利用非常宽泛,为了有一个更全面的意识,这里说的平安危险没有局限在登录这一点上,所有应用手机验证码的场景都可能存在。这里的应答策略次要是站在零碎开发者的角度,通过各种技术计划来解决或者升高手机验证码的平安危险。

短信欺骗

诈骗者先获取到用户手机号,而后假冒金融机构、公权力部门、亲朋好友,在利用中输出用户手机号申请验证码后,向用户索要对应的手机验证码,用户稍不留神可能就会造成金钱损失。

针对此类问题,零碎开发者能够思考如下一些计划:

  • 在验证码中申明:工作人员不会索取,打死也不要透露给他人。不过人在一些非凡状况下是不会理睬这些正告的。
  • 跟踪用户的罕用登录特色,比方获取验证码时的设施、IP、WIFI、地区不是罕用的,零碎就能够马上短信或者语音告诉用户可能存在平安危险,请审慎操作;零碎还能够间接降级安全级别要求更多的验证形式,比方须要再次获取验证码、输出平安码、刷取指纹、辨认人脸、插入 U 盾等等验证形式。

还有一种绝对荫蔽的欺骗形式,诈骗者间接向用户发送仿冒钓鱼网站的地址,用户在钓鱼网站获取验证码时,诈骗者拿着用户手机号去实在网站申请验证码,此时用户会收到一个实在的验证码,用户在钓鱼网站输出验证码后,诈骗者就能够拿着这个验证码去实在网站应用。

针对这种状况,前边的辨认用户罕用登录特色的形式依然无效。此外短信平台和电信运营商也有责任对短信内容进行把关,短信平台须要验证发送者的实在身份、审核短信内容,并提供动静的流量管制机制,这样能够过滤掉绝大部分欺骗短信。

其实电信运营商是可能辨认手机地位的,如果电信运营商可能提供一种平安的地位认证服务,也能够解决大部分验证码欺骗问题,比方前端提交验证码认证时携带电信运营商提供的地位标识,利用服务商能够拿着这个地位标识去找电信运营商验证地位,当然这只是一个构想,事实中还没有这种办法。

短信攻打

可能有两种场景下的短信攻打:

  • 用户在前端不停的点击获取验证码,可能是放心收不到验证码,也可能是失去了期待的急躁,也可能是歹意向别的手机号发送。
  • 攻击者间接调用发送验证码的接口,在极其的工夫发送大量验证码申请,可能是发给某个用户也可能是一批用户。

此类操作首先会节约短信资源,给利用服务商造成损失;歹意攻打还会向无辜的用户发送大量短信,造成骚扰攻打。

应答这种问题,能够思考如下一些计划:

  • 减少其它验证。

    获取短信验证码之前必须先通过这些验证,比方图形验证码、滑动验证码、数学公式验证码等等。这些形式能够减少发送短信验证码的难度,升高人工的发送速度,尽量避免机器人主动操作。

  • 对操作进行限流。

    比方当初前端常见的发送短信验证码倒计时,个别每次申请验证码后通过若干秒能力再次发送。因为如果攻击者获取到了发送验证码的服务接口,就能够解脱前端逻辑的限度,所以后端也能够采纳同样的策略,对设施 Id、手机号、IP、用户、业务类型等等,以及它们的各种组合,进行频率管制。利用开发者还能够依据发送后果特色来进行管制,比方空号率,如果空号太多则阐明可能是机器人随机生成的手机号。在繁多频率的限度根底之上,还能够减少更多的工夫管制,在分钟、小时、天等工夫维度上做不同的阈值限度。

  • 给用户提供一个短信退订入口。

    用户频繁收到非本人被动发动的验证码短信时,能够提供一个退订入口,让用户在短时间内敞开短信验证码,应用服务此时能够疏忽给用户发送验证码的申请,或者间接去掉发送验证码的性能入口。

然而这种管制要尽量以不影响用户的失常业务操作为前提,否则就得失相当了。

  • 比方图形验证码的难度不要太高,毕竟大部分业务不是 12306,你照搬过去可能就会画蛇添足。
  • 再比方对于限流管制,假如失常用户个别只在一天的某些时候进行操作,不会一天 24 小时都在做某一件事,则能够这样做:每个手机号每小时只能发送 X 次,每天只能发送 Y 次,这两个数值要合乎 X<Y & 24*X\>>Y。
  • 对于重大的攻打,应该设置熔断机制,此时不得不就义可用性。比方短时间涌入了大量针对不同手机号的验证码需要,很可能是受到了 DDOS 攻打,因为资源无限,此时失常用户的操作也会受到影响,能够依靠全局限流,触发限流时间接敞开验证码服务一段时间。

网络窃听

假如用户收到了登录验证码,输出正确后提交服务端验证。在从手机端到服务端的传输过程中,会通过很多的网络设备和服务器零碎,登录提交的内容有被拦挡获取的可能,此时攻击者就能够阻断申请,本人拿着用户的手机号和验证码去登录。

应答这种问题,个别须要对网络传输内容进行加密,比方当初罕用的 https 通信,能够保障两端之间的传输内容平安,不被窃听。对于传输平安,个别这样解决也就够了。

不过 https 也不是银弹,如果有攻击者在客户端偷偷导入了本人的证书,而后让网络申请都先通过本人进行代理,再发送到指标地址,则攻击者还是可能获取到申请内容,想体验这种形式的能够应用 fiddler 试试。还有 https 证书存在错发的可能,如果给攻击者发放了他人的证书,此时平安传输也就没什么意义了。

为了更高的安全性,传输内容能够在利用中加解密,客户端对要传输的数据依照与服务端的约定进行加密,而后再发送到网络,攻击者截获后,如果没有无效的解密伎俩,则能够保证数据不被窃听。加密的重点是保障密钥平安,不被窃取和替换,能够采纳其它平安信道传输,甚至线下传递的形式。对于验证码这种仅做验证的数据,还能够通过加盐后进行慢 Hash 运算,攻击者即便拿到了传输内容,要进行破解的难度也相当微小。

本地窃听

如果零碎上装置了恶意软件或者非官方版本的软件,特地是在盗版零碎、被 Root 或者越狱的手机零碎中,攻击者也能比拟容易的拦挡并窃取短信验证码;同时网络窃听中的加解密也可能失去作用,因为软件曾经不可信,在不同的操作之间有么有产生什么猫腻,很难确定。

最近几年在挪动设施上引入了一个称为可信执行环境(简称 TEE)的概念,独立于操作系统,独自的利用,独自运行,有的甚至有独自的处理器和存储,内部很难进入和破解。一些要害的操作都封装在这里边,比方指纹的采集、注册和认证,密钥的生成和应用,版权视频的解码和显示,等等。如果把短信验证码的解决也放在这里边,无疑会平安很多,不过这要解决很多通信方面的问题,收益与老本可能不成正比。在台式机中这一技术还所见不多,可能台式机的环境曾经有了比拟成熟的平安体系,不过从挪动端迁徙过去难度应该也不大。

短信嗅探

短信嗅探也是一种窃听技术,不过是通过攻打电信网络通信的形式。

当初手机个别都应用 4G、5G 网络了,然而“短信嗅探”技术只针对 2G 网络,不法分子通过非凡设施压抑基站信号,或者选择网络品质不佳的中央,或者应用 4G 伪基站坑骗手机,这会导致网络降频,使手机的 3G、4G 通信升高到 2G。

2G 网络下,只有基站验证手机,手机不能验证基站,攻击者通过架设伪基站,让指标手机连贯上来,而后就能获取一些连贯鉴权信息,再假冒指标手机去连贯真基站,连上当前拨打攻击者的另一个手机,通过来电显示失去指标手机号码。

基站自身并不会用特定方向的信号与每部手机通信,而是向周围以播送的模式发送信号。所以每部手机实际上也是能够接管到其余手机的信号,2G 网络传输数据时没有加密,短信内容是明文传输的,就能够嗅探到指标手机的短信。加之 2G 通信协定是开源的,所以这件事的技术门槛并不高。

因为这种攻打要求手机不能挪动,如果基站切换就没用了,所以攻打个别抉择夜深人静的时候。对于普通用户来说,睡觉的时候能够抉择关机或者开启航行模式;另外开明 VoLTE,能够让电话和短信都是走 4G 通道,不过网络降级很难防备;或者买个能辨认伪基站的手机,不过没方法保障百分百可能辨认;或者就只能等着挪动运营商敞开 2G 网络了。

对于利用零碎开发者,应该意识到通信通道的不安全性。必要的时候开启双因子验证,除短信验证码外还能够应用短信上行验证、语音通话传输、专用明码验证、罕用设施绑定、生物特色辨认、动静抉择身份验证形式等等多种二次验证办法。

重放攻打

假如某些交易服务须要通过短信验证码来验证用户的身份。如果有攻击者截获了交易申请报文,而后屡次发送到服务端,服务端仅查看了验证码是否正确,则可能理论产生屡次交易。此时攻击者都不须要解密传输内容。

此时应该限度验证码只可能应用一次,服务端收到交易申请时首先查看验证码,查看通过后将验证码置位或删除,而后再解决交易,不论交易是否胜利,验证码都不能再次应用。另外还应该在生成验证码时设置一个较短的有效期,如果用户没有理论提交,攻击者也必须在有效期内能力应用,减少攻打难度。

当然你也能够应用更通用的防重放伎俩,比方每次申请验证码都先从后端获取一个随机数,随机数如果曾经应用过则不能再次应用,随机数如果不存在也不能解决申请。当然随机数也能够在前端生成,服务端如果收到了反复的随机数则拒绝请求,然而须要避免传输过程中随机数不被篡改,能够通过密钥签名的形式。


以上就是本文次要内容,满腹经纶,如有错漏,欢送斧正。

播种更多架构常识,请关注公众号 萤火架构。原创内容,转载请注明出处。

正文完
 0