再见了，接码平台：交互式语音验证码

和传统意义上的验证码（CAPTCHA）专治“人机识别”有些不一样，有时我们需要确认用户是否正在持有某个特定的设备（当然也可以顺便做一下人机识别）。

此时，我们通常采用短信验证码来进行这个确认过程。由于接码平台的存在，会使得这条期望的信任链断裂，用一个应景的称呼就是“共享手机号”。

（有些接码平台还有海外手机号）

这样很烦，我们需要想一种方法，使得“共享手机号”的方式无法继续维系或成本变得畸高。

在接下来的文章中，我将用“验证码”这个简称来特指“通过手机号下发的验证字符串”；如果要指代单纯图灵测试的验证码，我将用“CAPTCHA”这个单词。

一、接码平台的“弱点”

前面刚“怼完”打码平台，现在又有一个艰巨的怼接码平台的任务，感动的一夜无法入睡。哎……等等，这俩者会不会有点关联？

接码平台负责接收数据，打码平台负责处理和响应数据。它们两者割裂开来看都是单工的，即接码负责单向接收数据，打码负责单向处理数据。而我们的验证码（包括CAPTCHA）通常也是单工的，并没有进一步双向交互的设计。这会不会就是接码平台的弱点呢？

这里顺便提一下上行短信。上行短信验证码的思路是要求用户以短信的形式主动发送某些特定字符到特定号码的方式完成验证，其实质仍然是单工或者半双工的。

当然了，上行短信其实很坏。卡商的手机卡数以万计，每卡的平均余额每多1元，就要付出上万倍的资金沉淀。所以卡商不太喜欢卡里有很多钱，只希望每张手机卡跑完全部业务后刚好余额小于等于0。

众所周知，发短信是要付钱的！在流量费用这么低的情况下每条短信是毛钱你还不能说脏话。卡里欠费了的后果自然是停机。停机什么概念，那就是连短信都收不到了啊。卡商的卡还等着收码呢，你这停机了生意还做不做的啊？

所以，上行短信出来之后，收效一时间很不错。不过，最近在集团卡、物联网卡出现之后（统一付费），上行短信也逐渐要被呵呵了。

（某著名软件的上行短信验证码）

二、IVR登场

大家应该都有拨打客服热线的经验，接通之后往往会有个甜美的女声“普通话请按1，For english press 2…”，我们在手机键盘上按下对应的按键之后，后端的话务系统就会按照设定完成相关任务。

等等，话务系统是怎么知道我们按下按键的？

死神小学生剧场版“战栗的乐谱”讲了一位万年不老的黑框眼镜男子与一位如花似玉面容姣好的妙龄女子，用他们最擅长的音乐合唱“远程”拨打了报警电话这么一件事情。故事中，死神小学生不小心告诉了远程拨号的原理——DTMF（Dual-Tone Multi-Frequency），双音多频信号。

（死神小学生剧场版对DTMF的解说）

DTMF是电话系统中用户信令的一部分，用来传递某些特定的用户信号。主叫话机向电信交换机发起拨号请求时，携带的号码信号一般就通过DTMF传递。而我们常见的话务系统叫你按这键按那键也是依靠DTMF传递这个关键信号的。有个术语称呼这个“话务系统”——IVR（Interactive Voice Response），交互式语音应答。

（DTMF信号的声纹）

DTMF的具体原理大家可以去看《他改变了……》，哦不对，应该去看《战栗的乐谱》，学习一点人生的经验，这里就不再展开。

如果我们把IVR用在验证码上，会变得怎样？

系统要求用户验证手机 -> 用户输入手机号 -> 系统发起主叫 -> 用户接听语音提示 -> 手机键盘输入验证码 -> 验证通过，美滋滋。

在这个过程中，用户脱离了传统的前台接口提交验证码。也就是说，除非用户主动在手机上输入验证码，否则是无法通过其他的过程向服务器表达其希望进行验证的意图。

换句话说，我们把原先验证码“异步”的过程“同步”了，从多个环节的单向流动整合到了一个环节的双向流动。

三、对抗语音识别

正当我美滋滋的时候，一旁的小伙伴给我泼了瓢冷水——这还有语音识别呢，咋整？

大部分的语音验证码非常蠢蛋，电话那头的小姐姐巴不得用字正腔圆普通话一甲的播音腔嘴把嘴地教你汉字的发音。除去性别歧视和什么女权男权平权概念外，这对STT（语音转文字）也太友好了吧？

我拿某个友商的一段语音验证码做了个试验。你看看，你看看人家，多么清晰的波纹啊！这也别他喵STT了，直接多抓几次，把0-9的发音波纹都记下来，对后头几个波做个简单匹配不就好了？

（某友商的语音验证码声纹图，大家可以猜猜验证码是啥）

这样可不行，我们这么骚包的思路岂能被区区STT怼了回去？

校验环境音。

语音识别出来的结果要通过DTMF传递回“服务器”，那自然不能挂断通话。同志们，通话是双向的，思路是交互的。你在YY电话那头播音腔小姐姐的时候，你的喘息声正在通过麦克风传递过去！

有人会抬杠，说我输入验证码的时候从不喘息，连屁都不敢放一个，这样不就可以混淆正常用户与STT自动提交的区别啦？

马克思主义哲学告诉我们，实践是检验真理的唯一标准。为了打这种接电话不出声的家伙的脸，我决定花费整整5毛钱，通过手机进行各种环境之下不同环境音的采样。

（欢乐的办公室）

（孤独的走廊）

（只有一个人的会议室）

（蹲坑超过30分钟的卫生间）

（录音室）

女士们先生们，各位家长各位来宾，五个地方只有录音室没有环境音（但是仍然有白噪音）。正常人接电话至于跑到录音室接么？还真有啊，那活该被毙（商务微笑脸.jpg）。

经过上面价值5毛钱的科学的实验证明了，对环境音的识别在某些程度上是可以足够与自动STT对抗的。

四、对抗实时人肉识别

自动对抗看起来是没问题了，那人肉识别怎么办？我国还有一大堆家庭主妇、大学生、灵活就业人群长期盘踞在打码平台上。

理论上，语音实时双向传输对基础设施和技术积累的要求很高（参考各种直播平台、各种直播云），在实践中往往会被弱化为延迟若干秒的“伪直播”方式。那样的话，我们可以通过播报完毕语音与获取到输入之间的时间差来识别这些明显存在问题的“验证请求”。

先不说打码平台和接码平台如何完成语音传输的实施双向对接，假使真有这么一个实时的打码平台提供人肉的识别，我们怎么办？

当然选择原谅……咳，当然选择提升问题难度啦。

某打码平台上一个“20汉字识别”的题目价值200题分，约合人民币0.2元。一般来说，常年活跃在打码平台上的小伙伴都具有单身数十年练出来的手速，保守估计一分钟这样的题能做3道，也就是说每分钟打码收益约0.6元。

（某打码平台上题分最高的题目）

如果我们把验证码语音提示变成：

（前面一曲15秒的致爱丽丝）……欢迎您使用XXXX验证系统，为了您的信息安全，现在，请您依照语音提示进行验证……请您按下5号键，然后按下井号键……（等待输入）……请您再按下9号键，然后按下井号键……（等待输入，可以重复N次）……验证完成。

这么折腾下来，单次验证时长如果算上等待电话呼入的3秒钟，起码1分钟起步。这样的话，打码平台上题分的设置就会变高。羊毛党花上几万块钱屯了几万个账号，回头被厂商发现一下子全给封了，要我我也疯了。

等到收码、打码付出的代价或者承担的风险超过薅羊毛带来的业务盈利后，这条路自然会被堵上。

五、交互式语音验证码的弱点

要说这个方案的弱点吧，当然有。没有弱点的那是吴京。

很显然，交互式语音验证码对用户体验的下降是很厉害的。尤其是启用了分段验证时，用户需要花费一到两分钟才能完成一次验证过程。这样用户会很气，业务指标就会下降；业务老大就很气，往往你的年终奖水平也会随着下降。

而且，语音验证码是具有成本的。每次通话都需要以分钟数对服务供应商付费，一般来说这样的费用会在几分钱每分钟左右。不过，比短信好的地方在于，语音不接通不收费，美滋滋。

另外，纵观全文，我们似乎没有找到一家使用了这样的验证方式的厂子。没有买卖就没有杀害，自然也就没有接码平台愿意去做这个方向的技术研究。如果哪一天，BAT或者其他大厂采用了这方案，或许会在巨大的利润诱惑下，迅速产生交互式验证码的接码服务。有理由相信，金钱是技术最好的驱动力，这天可能迟早会到来。

要不然，干脆改一改标题，祈祷恳求拜托希望大厂千万用上这个玩意儿，放我们小厂一条生路如何？