手机号已经成为了目前绝对的主流注册方式，大多数产品的帐号体系也是依赖手机号来建立的，但如果用户手机号不使用之后，再被运营商放号，新的用户拿到了这个手机号，那么该不该给这个用户注册呢？产品的安全机制如何保证？今天来临摹下大厂的做法，看新浪微博是如何解决app中手机号因运营商回收并再次售出导致的帐号问题。
首先，传统PC端使用邮箱注册的方式已经逐渐被手机号注册取代，原因有以下三点：
手机号注册的方式更加安全，快捷；
通知更加及时，短信无网络也能触达；
拿到了手机号就能对用户进行短信营销，达到召回用户、宣传活动等目的。
所以，手机号逐渐成为了产品的帐号体系中主流的注册方式。
但是，和PC时代通过邮箱注册不同，手机号存在着被运营商回收再次放出市场的问题。
将手机号作为帐号体系，就会产生当用户更换手机号后，旧有的帐号需要安全认证时无法拿到短信验证码（因为手机号已经被运营商卖给了别人），再次拿到该手机号的用户无法注册等一系列问题。
接下来进入主题，各位乘客坐稳了，开始发车…
我们通过了解背景，分析产品存在的问题，临摹新浪微博的解决方案，来看大厂是如何解决此类问题的。
一、背景
1、停用和购买手机号的场景
用户产生手机号停用和购买新手机号的行为大多数发生在更改手机号时，以下场景都可能导致更换手机号码，例如高考考到别的城市、毕业了到其他城市发展、更换工作地点、出国、搬家等等
更改手机号最大的原因是为了省钱，毕竟在国内，异地拨打电话是需要收漫游费的，贵不说，连流量也区分省内和省外，长期居住不换号码是非常土豪的做法。
移动漫游费指的是离开归属地以后拨打和接听电话产生的费用；
长途费指的是在归属地拨打除归属地以外的电话所产生的长途费用。
此外，除了用户更换手机号会产生停用和购买手机号的行为外，欠费停机等也会导致手机号被停用，青年购买手机后也会产生购买手机号的行为，这里不再展开。
2、二次放号的场景
一方面，用户有购买手机号的需求，但另一方面，手机号码是11位的号码，总量有限，不可能永久占用，于是运营商除了会将全新未使用的手机号销售给用户外，还会将以往已使用过的手机号回收之后过一段时间后重新投入市场中（以下简称二次放号）。
例如手机号A如果因为欠费或者用户主动要求销号，在被销号后就会被运营商回收，过一段时间后手机号A就会重新投入市场中。
三大运营商的销号时间不同，大体上可以分为销号和回收两个阶段。
销号阶段，一般为3个月
回收阶段，一般为1-3个月
所以，一个号码从销号到重新投入市场，一般最快需要4个月的时间。
二、存在的问题
现实中存在二次放号的问题，如果产品的体量不大，注册的用户数不多，这个问题还可以通过客服来解决，但是当产品注册用户数攀升到千万级或亿级的时候，每个用户都通过客服来解决，不仅顾客等待的要炸毛，客服也会炸毛。
先分析下二次放号对产品造成的影响，以下以a，b表示帐号ID，以A、B表示帐号对应的手机号，小明和小红表示用户。
1、注册
场景1：小红通过运营商购买了二次放号的手机号A，来到产品的注册页面，发现手机号已经注册了？自己没法注册自己的帐号？？
于是可能产生两个问题：
若产品没有做好注册引导，小红将无法注册帐号；
若产品没有安全措施，不明真相的小红通过忘记密码的渠道重设了小明帐号a的密码，登录进去之后，OMG！
为什么上面那么多个人信息，而且都不是自己的，小红毫不费劲的看到了小明的所有个人信息！不知道密码被改的小明，也没法登录产品了。
小红异常纳闷，同时觉得产品太不安全了。
2、登录
场景1：小明换了手机号B同时买了部新的iPhone8 Plus手机，但产品中的安全措施发现是新的登录设备后，要求小明通过手机号A进行短信验证才能登录，由于手机号A已经在小红手中，小明根本没法拿到短信验证码，登录失败！
场景2：小红通过手机号A更改了小明的帐号a的密码，这时吃瓜群众小明使用原有的设备正常打开app，Token失效来到登录页面，输入手机号A和旧有的密码，发现提示“手机号码或密码错误”，小明登录失败，纳闷“帐号被盗了？”
场景3：小红通过注册流程使用手机号A注册了新的帐号b，系统自然解绑帐号a和手机号A的绑定关系，将手机号A绑定到帐号b上。
小明来到登录页面，输入原有的帐号和密码，依旧会提示“手机号码或密码错误”，登录失败（因为此时手机A绑定的是帐号b，密码是帐号b的密码），可怜的小明可能觉得“我去，谁盗了我的帐号？这产品太不安全了”
于是产生的问题是：
若产品中有登录保护等安全机制，小明无法在新设备登录自己的帐号；
若小红能修改密码，小明帐号密码被改，无法登录，小红能看到小明的所有内容；
若产品允许小红注册一个新的帐号，小明帐号a与手机号A解绑，小明无法登录帐号。
3、找回密码
场景1：还是倒霉的小明，更换手机号后，神经特别大条，连密码都忘记了，来到找回密码的页面，但要求通过手机号A+短信验证码的方式来重置密码。
小明懵B了，坑爹呢，手机号都换了，短信验证码自己怎么可能拿的到，重置密码失败。
场景2：拿到手机号的小红通过重置密码能轻松的更改小明帐号a的密码。
产生的问题是：
若产品中的找回密码没有考虑接收不到短信验证码的场景，小明无法重置密码，无法登录产品；
若产品中的找回密码没有相应的安全机制，小红可以轻易的更改小明的密码。
三、解决方案
下面开始临摹产品，以新浪微博为主，中间穿插一些其他app的做法，看大厂的产品是如何解决二次放号的问题的。
依旧以a，b和密码Aa，密码Bb分别表示帐号ID和帐号对应的密码，以A、B表示手机号，小明和小红表示用户。
1、注册流程
用户进入到注册流程但手机号已注册，有两种可能：
自己之前注册过了，但是忘了注册过；
第一种情况，需要引导用户去登录或通过找回密码来找回密码；
第二种情况，需要引导用户去注册。
解决方法是在通过短信验证手机码后，询问这个帐号是否自己之前注册的？同时提供一些身份信息让用户去判断。
若用户认为这个帐号是自己的，那么直接登录成功；
若用户知道这个帐号不是自己，引导用户去设置登录密码，设置成功之后，解绑手机号A和帐号a，注册帐号b，绑定帐号b和手机号A。
如果产品中有涉及钱财或隐私的内容（例如支付宝涉及钱财，图片社交涉及隐私图片，微博QQ等涉及社交隐私等），当用户选择帐号“是自己注册”之后，还需要验证下用户身份的真实性，这部分放到安全机制中统一讲。
总结注册流程如下：
由此，注册的两个问题解决了：
（1）若产品没有做好注册引导，小红将无法注册帐号，如何解决？
答：通过引导用户辨识是否是自己此前注册的账号，针对不同的情况分别处理。
（2）产品没有安全措施，小红直接登录或通过忘记密码的渠道重设了密码，登录进去之后看到小明信息，如何解决？
答：增加安全措施，判断需要进行身份验证时，通过身份验证后才可以直接登录或重置密码。
2、登录流程
为了不影响大部分用户进行登录，登录页面并不适合做的很复杂，只需要给出口子，当用户遇到问题的时候能一步步引导用户去解决即可。
以新浪为例，新浪微博采用的是“登录遇到问题？”将用户可能遇到的问题收纳了起来，当用户点击后弹出“找回密码”/“找回登录名”/“客服中心”给用户进行选择。
另外，如果产品有记录安全设备，那么可能还需要进行身份验证，而身份验证也涉及到手机号，这部分也放入安全机制中讲述。
这里提供一个自己脑洞出的解决帐号a缺失了手机号无法登录问题的方法。
解决方案是——新增一个字段用于记录用户的历史手机号，当小红注册了帐号b，同时绑定了手机号A后，小明的现有帐号手机号即为空，但是历史手机号为A。
当用户登录的时候，先检测“手机号+密码”是否能正常登录，如果可以直接登录，若不可以，再检测“历史手机号+密码”是否能登录，如果能登录则引导用户去设置手机号。
流程如下：
我们再回过头看二次放号产生的登录问题：
（1）若产品中有登录保护等安全机制，小明将无法登录自己的帐号。
答：在安全机制中通过其他方式验证小明身份；
（2）若二次放号后小明帐号a的密码被更改，小明通过原有的手机号A+密码无法进入帐号。
答：让小明去重置密码，在重置密码流程中新增“获取不到验证码”通过身份验证的方式来重置密码；
（3）若产品允许小红注册一个新的帐号，小明帐号a与手机号A的就会解绑，小明无法登录帐号。
3、忘记密码流程
用户进入密码的场景有四种：
真忘了自己密码；
二次放号后，小红买了新手机号，提示已注册，如果没有相应的注册引导，于是来到忘记密码，改了小明帐号的密码；
二次放号后，小红改了小明的密码，小明无法登录，来到忘记密码页面；
二次放号后，小红注册了手机号A，帐号a的手机号为空，小明无法登录，同时真把自己密码Aa忘记了，所以没法通过登录页面的“历史手机号+密码“登录后来重新绑定手机号，于是来到忘记密码页面。
常规的流程是通过已有手机号+短信验证码来重置密码，但为了避免上述的小红直接将小明帐号密码改了的问题，需要有安全机制，这部分放到安全机制中讲述。
另外，不管小明是被改了密码，还是手机号都没了密码也忘了，都属于接收不到短信验证码的问题，这时候要留出口子让这部分用户能通过身份验证自主的重置密码，这部分也放到安全机制中讲述。
总结忘记密码流程：
再回过头看二次放号产生的忘记密码问题，产生的问题是：
（1）若产品中的找回密码没有考虑接受不到短信验证码的场景，小明无法重置密码，无法登录产品。
答：增加身份验证流程，验证通过后可重置密码；
（2）若产品中的找回密码没有相应的安全机制，小红可以轻易的更改帐号a的密码。
答：增加安全机制，验证通过后可重置密码。
4、安全机制
上述的注册，登录，忘记密码流程中，为了避免二次放号后用户可以直接登录成功，都需要有一个验证身份的流程。
但为了不影响正常用户的使用，需要先判断是否需要进行身份验证，以下情况是可以不用身份验证的：
用户注册不到4个月（前面提到，运营商二次放号至少需要4个月，若有特殊情况，找客服，不考虑）；
常用的设备不需要身份验证（例如使用超过了7天）；
设置为安全的设备不需要身份验证（例如用户已经将设备加入了“受信任设备列表”中）等。
如何进行身份验证？
（1）好友辅助验证
QQ和微信采用的是让两位好友帮忙辅助验证——将验证信息转发给你的好友，页面提示让好友确认是本人后再点击验证通过，两位好友帮忙验证通过后即可通过身份验证。
这种验证方式安全度极高，但是也麻烦，适用于社交类的产品。
（2）历史信息验证
例如淘宝历史购买的商品记录9选1，好友头像15选2，回答上一部使用的手机型号是什么，最近添加的好友是谁，最近一次的购物地点在哪，最近一次购买的飞机票是去哪，等等。
需要注意的是，微信虽然采用了这种验证方式，但是好友头像和名字变化太快，用户可能自己都记不住，实际的体验没有想象中的好。
支付宝初期也有采用类似的做法，但是因为两次9选1，1/81的概率还是不安全，弃用了。
但9选1,15选2等在安全系数要求不高时还是可以采用。
（3）用户身份验证
如果产品中有用户独一无二的身份信息，还可以采用用户信息的验证方式，例如输入“XXX”完整的身份证号码，银行卡，社保卡，某医院的就诊卡等。
（4）通过已添加的其他“受信任的手机号”通过验证
例如新浪的做法，用户除了有一个登录的手机号外，还可以添加多个“受信任的手机号”来辅助验证，当登录的手机号无法接受到短信，通过“受信任的手机号+短信验证码”的方式也可通过验证。
（5）密保问题认证/邮箱认证
早年PC端特别流程的设置三个密保问题，即使接收不到短信验证码，通过密码问题也能完成身份认证，但是这种方法最大的问题是，用户自己也经常忘了密保问题，所以有点鸡肋。
邮箱认证因为移动app中大部分抛弃了邮箱注册，使用的范围有限。
（6）客服申述等
客服申述是最终极的大招，让用户填写注册信息，历史信息，身份信息，上传证件照来完成认证，但是比较费时，同时会占用客服资源，属于不得已而为之的做法。
不同的产品的解决方案不同，需要根据产品自身的特点来设计，由于是临摹新浪的安全机制，所以特别讲述下新浪的做法。
5、新浪的登录保护机制
（1）登录保护机制
提供登录保护的开关，开启后，每次登录新的设备的时候，都需要进行手机号验证。
（2）受信任的手机号
可添加新的受信任的手机号，之后所有涉及身份验证的环节，除了可以使用原有的登录手机号外，还可以使用“受信任的手机号”
例如小明有了手机号A，同时把自己老婆的手机C设置了“受信任的手机号”，完美解决了二次放号的问题。
（3）受信任的设备
开启了登录保护之后，每次登录新设备都需要身份验证。
移动端设备在验证通过的会自动添加进入“受信任的登录设备”，PC端设备登录需要认证的时候，就可以使用不同的“受信任的设备”来认证登录。
此外，登录记录会自动添加已登录的设备到“最新登录记录”中，可将陌生的登录设备踢下线。
流程图如下：
上面提及的新浪家的做法，实际上只是其帐号体系其中的冰山一角，特别是相应的安全机制，没有彻底摸透，只能知道大概，仅供参考。
另外，如果产品体量小的话，二次放号的场景可以不考虑先，毕竟帐号体系这套工程做下来工作量很大。在体量小的时候，把业务做精，努力提高数据量才是最高优先级吧，产品体量小时，这类的问题数量不多，可以先抛给万能的客服姐姐帮忙解决，等业务真正做起来后，再考虑完善的帐号体系。
不同阶段，产品需要的安全等级也不尽相同，不是每个产品都需要做到如同支付宝，微信，QQ这样的安全等级，也是视产品的业务而定。
