账号体系设计：如何解决手机号二次使用导致的账号问题(3)

例如淘宝历史购买的商品记录9选1，好友头像15选2，回答上一部使用的手机型号是什么，最近添加的好友是谁，最近一次的购物地点在哪，最近一次购买的飞机票是去哪，等等。

需要注意的是，微信虽然采用了这种验证方式，但是好友头像和名字变化太快，用户可能自己都记不住，实际的体验没有想象中的好。

支付宝初期也有采用类似的做法，但是因为两次9选1，1/81的概率还是不安全，弃用了。

但9选1,15选2等在安全系数要求不高时还是可以采用。

（3）用户身份验证

如果产品中有用户独一无二的身份信息，还可以采用用户信息的验证方式，例如输入“XXX”完整的身份证号码，银行卡，社保卡，某医院的就诊卡等。

（4）通过已添加的其他“受信任的手机号”通过验证

例如新浪的做法，用户除了有一个登录的手机号外，还可以添加多个“受信任的手机号”来辅助验证，当登录的手机号无法接受到短信，通过“受信任的手机号+短信验证码”的方式也可通过验证。

（5）密保问题认证/邮箱认证

早年PC端特别流程的设置三个密保问题，即使接收不到短信验证码，通过密码问题也能完成身份认证，但是这种方法最大的问题是，用户自己也经常忘了密保问题，所以有点鸡肋。

邮箱认证因为移动app中大部分抛弃了邮箱注册，使用的范围有限。

（6）客服申述等

客服申述是最终极的大招，让用户填写注册信息，历史信息，身份信息，上传证件照来完成认证，但是比较费时，同时会占用客服资源，属于不得已而为之的做法。

不同的产品的解决方案不同，需要根据产品自身的特点来设计，由于是临摹新浪的安全机制，所以特别讲述下新浪的做法。

（1）登录保护机制

提供登录保护的开关，开启后，每次登录新的设备的时候，都需要进行手机号验证。

（2）受信任的手机号

可添加新的受信任的手机号，之后所有涉及身份验证的环节，除了可以使用原有的登录手机号外，还可以使用“受信任的手机号”

例如小明有了手机号A，同时把自己老婆的手机C设置了“受信任的手机号”，完美解决了二次放号的问题。

（3）受信任的设备

开启了登录保护之后，每次登录新设备都需要身份验证。

移动端设备在验证通过的会自动添加进入“受信任的登录设备”，PC端设备登录需要认证的时候，就可以使用不同的“受信任的设备”来认证登录。

此外，登录记录会自动添加已登录的设备到“最新登录记录”中，可将陌生的登录设备踢下线。

流程图如下：

上面提及的新浪家的做法，实际上只是其帐号体系其中的冰山一角，特别是相应的安全机制，没有彻底摸透，只能知道大概，仅供参考。

另外，如果产品体量小的话，二次放号的场景可以不考虑先，毕竟帐号体系这套工程做下来工作量很大。在体量小的时候，把业务做精，努力提高数据量才是最高优先级吧，产品体量小时，这类的问题数量不多，可以先抛给万能的客服姐姐帮忙解决，等业务真正做起来后，再考虑完善的帐号体系。

不同阶段，产品需要的安全等级也不尽相同，不是每个产品都需要做到如同支付宝，微信，QQ这样的安全等级，也是视产品的业务而定。

文章作者系 @朱利安 未经许可，禁止转载。

（编辑：ASP站长网）