【复盘】新设备登录短信验证

涉及用户隐私、金钱等产品在用户账户安全上更应该下功夫。比如账号密码强度验证，账号多地同时登陆处理以及账号在新设备上登录验证等。前段时间公司做了新设备短信验证，产品逻辑上很简单，但是其中却有很多坑，今天来复盘一下。

1.产品逻辑

在登录页面输入账号密码点击登录后，先检测登录密码是否正确，密码正确的情况下，该账号在此设备上是否是第一次登陆，如果是则跳转至新设备登录验证页面，不是则登陆成功。在换设备验证页面输入短信验证码，正确即代表验证成功，然后采用一定的技术手段标识此设备为非新设备，下次再登陆此账号时，就不会再验证设备。

2.页面设计

新设备短信验证

3.踩坑过程

看看，很简单是吧。于是乎花了个把小时就把需求文档和UI做好了，简单和开发说了下，就进入开发环节。

坑一：等到要上线时，测试妹妹发现，正常的流程没有问题，但是将APP卸载重装后，登录过的设备依然会要求验证设备。

问题就出在“采用一定的技术手段”上，开发在做的时候并未考虑全面，只是简单实现功能。接下来分析一下技术层面的问题，android系统和ios系统在技术处理方法上自然是不同，但是原理上基本相同。新设备需要短信验证，非新设备不需要短信验证，那么就需要得到这个设备的唯一标识。

android获取设备唯一标识的方法：

1）获取IMEI

缺点：需要用户给与获取手机信息的权限。

2）获取Mac地址

缺点：谷歌为保障用户隐私安全，android 6.0版本后，任何手机都是"02:00:00:00:00:00"这个默认的mac地址。

3）获取ANDROID_ID

缺点：1.手机恢复出厂设置以后该值会发生变化。2.某些设备是不会返回ANDROID_ID。

4）获取UniquePsuedoID

缺点：同一批次生产的设备UniquePsuedoID可能相同。

5）通过友盟等第三方接口获取

缺点：因为是第三方接口，所以有很多不可控因素。

ios获取设备唯一标识的方法：

1）获取UDID

缺点：为保障用户隐私安全，从IOS5.0开始，苹果宣布将不再支持用uniqueIdentifier方法获取设备的UDID。

2）获取UUID

缺点：这个值系统不会存储，每次调用的时候都会获得一个新的唯一标示符。

3）获取Open UDID

缺点：删除后再获取，值会不一样。

4）获取MAC Address

缺点：为保障用户隐私安全，iOS7后请求Mac地址都会返回一个固定值。

5）获取广告标示符（IDFA-identifierForIdentifier）

缺点：a.如果用户完全重置系统，这个值会重新生成。b.另外如果用户还原广告，这个值也会重新生成。

6）获取Vendor标示符 (IDFV-identifierForVendor)

缺点：卸载后，这个值会改变。

7）通过友盟等第三方接口获取

缺点：因为是第三方接口，所以有很多不可控因素。

可以看出，不管是ios还是android，大部分获取标识的方法都会存在卸载应用、更新系统后标识符会改变，或不可使用的问题。最终我们的android开发小哥哥用得是第5种方法，接的是友盟的接口，可以实现卸载APP重装后，登录不会再验证短信。ios采用了第二点获取UUID的方法，只是将这个方法加以优化：应用第一次启动时，会将获取的UUID存储在KeyChain中, 以后每次要使用UUID时，先看KeyChain是否为空, 如果为空则将UUID存储进去，如果不为空，则直接使用KeyChain里面的值。这种方法在用户卸载APP或重启设备,  KeyChain都不会清空，登录自然也不会再验证短信。

这样，我们就开心的上线啦。

坑二：上线后android报“设备不一致”的错误，强制用户重新登录，并需要验证短信。

经过开发排查，发现是友盟的问题，同一个设备在一定时间段内会提供两个不一样的设备标识。所以android最后也只有自己写代码去解决这个问题。最后采用的方法：获取IMEI的方式，这种方式必须用户允许给与权限，如果不给权限，还是会要求验证短信。所以在一定程度上还是未能完全满足需求。（现在市面上很多android系统的APP在安装过程中必须用户允许开启获取手机信息的权限，否则将不能使用此APP）

4.总结

虽然说需求上很简单，但是产品也需要了解基本的技术知识，防止上线后才发现各种问题。