不管是电商型平台，还是社区型应用，账号体系都是重中之重。没有成功的引导用户进行登录/注册的转化，则一切都是0。
而对于搜狗输入法、百度地图等工具型应用，账号体系也是提高用户体验的关键路径。
通过获取用户在不同终端的数据，分析挖掘用户行为，可提供如关键词联想等更个性化的服务。
以上我们可以看到，账号是APP中最不起眼的模块，却是提高用户粘性，减少用户流失，培养忠实用户的基础，是最底层支撑模块。
当其他页面疯狂的小步快跑，快速迭代的时候，账号则是安全易用即可。
下面Link将对知乎上关于账号关注量和浏览量最高的问题，表达下自己的观点和解答。
一、为什么第三方登录越来越受青睐
在今日头条、网易新闻中，第三方登录已被前置强化设计，原因是该类弱账号体系的APP中，即不涉及金融支付的APP中，第三方登录是最佳的选择。
优点：
极大的简化注册环节， 大幅减少可能因为注册繁琐带来的用户损失；
简化用户设置个人信息过程，通过第三方登录，直接获取用户头像昵称等基本个人信息，无需用户自行设置；
快速导入用户在第三方账号体系中的关系链，减少APP冷启动社交关系的成本；
通过第三方账号体系强大的社交链条，便于各类运营活动的病毒式传播；
节省用户的记忆成本，用户在使用多个应用时，只需使用第三方登录即可，无需记得每个平台的账户和密码；
缺点：
账号登录/注册成本极低，用户的owner意识较低，引起留存率不高。
通过第三方账号创建账号，若没有设计好合理的第三方和公司自身账户对接的方案，会导致同一个用户在平台上有多个账号的情况发生，后续可能带来大量客诉。
对于注重隐私的用户，因第三方登录导致自己的状态或者信息间接的被同步到第三方账户里的好友，造成极大的困扰。比如美团外卖的好友头条，在AppStore看到过用户大量的关于隐私信息的投诉。
事物总有两面，以上我们可以看到借用第三方登录的优劣势分析。特别是对于小公司而言，前期捆绑大厂如微信、QQ、微博的账号体系，是APP快速成长的最佳选择。
二、为什么越来越多的第三方登录需要强制绑定手机号
顺着上面的问题说，第三方登录是不涉及支付金融环节的弱账号体系APP的不二之选，但必须强调的是，对于淘宝、京东、美团点评而言，第三方登录一定且必须要验证手机号绑定。
原因是风险控制，风险控制，风险控制。
对于绝大多数的模块而言，产品设计希望让用户的使用体验尽可能流畅，使用路径越短越好。
但对于账号模块而言，产品经理面对的不仅是海量的普通用户，还有各类善于钻平台各类漏洞的恶意用户。
如果没有绑定手机号，恶意用户可在平台通过第三方账号创建大量的新账号，仅通过网络IP来源等渠道来杜绝是远远不够的。9.9元电影，1分钱吃汉堡等等新用户特惠福利的补贴，将被攫取殆尽。而且可以想见，淘宝上也会有大量的新人账号开始售卖。对于公司而言，将是巨额的资产损失。
如果没有绑定手机号，用户的账号信息易被轻易盗取。恶意用户可以轻易盗取平台活跃用户的账号，进行各类软文推广广告的恶意宣传，极大影响平台社区的质量，进而可能造成高质量用户的流失。
如果没有绑定手机号，一个普通用户也会有多个账号，比如微信授权和qq授权之后用同一个手机再进行授权。每个平台用户的userid是系统里唯一标识用户的字段，强制用户绑定手机号，可以将第三方账号生成的Open ID和手机号进行关联，以此让绑定过的第三方账号拥有同一个User ID，便于公司的用户信息管理维护。
当然第3点的重要性，远没有前2点严峻。
世界上有千千万万的好人，只有一小部分的坏人，但为了社会秩序的正常运转，事实证明，道德的管制是远远不够的，因此诞生了法律。
账号体系的设计与我们生处的大社会相同，产品经理恰若拥有达摩克利斯之剑，在善恶之间权衡，不断努力让正常用户极易登录，对非正常用户极难登录。
三、为什么现在PC网站登录都默认使用扫码登录的方式
继续顺着上面的问题说：
第三方登录强绑手机号是为了风险控制，而现在越来越多的网站例如淘宝、京东、点评，默认的登录方式都修改成了扫码登录，原因依然是风险控制。
随着科技的发展，密码登录的方式已经越来越引人担忧。在网上使用密码登录的方式，存在强度不够、易被撞库和网站钓鱼三大风险。
在PC电脑上使用密码登录，早已是最高频的盗号发源地。
扫码登录能够更为有效的减少输入密码次数。在帐户已经跟智能手机绑定的前提下，通过手机扫描电脑屏幕上出现的二维码，即可完成登录认证。
跟密码登录不同，扫码登录无法被随意复制，用起来正如京东上所说的，免输入，更快，更安全。
但扫码登录依然存在着一些不小的问题。
从用户体验来说，用户在电脑前，需拿起手机扫描二维码，在手机点击确认登录，然后返回网站查看登录状态，设备的更替浏览，流程相对繁琐。
从安全风险来看，点评在推行扫码登陆后发现，仍有不法分子伪造点评的登录二维码，诱导用户登录，获取相关数据。
四、总结
综上，我们可以发现账号模块，不得不更多的考虑恶意用户的行为，并且为该类用户加强了安全登录体系的设计，进而可能影响到普通用户的登录体验。
除了上述的风险控制外，账号也是每天客诉最多的领域，每一个账号登录失败的提示语都可能成为用户投诉的信息点，每一个账号体系的流程，考虑不周，都可能造成用户投诉的猛增。
在负责点评账号体系的半年里，深刻感觉到自己有以下两方面的成长。
思维逻辑的严谨性，日常与账号开发一起，不断的思考极端情况的流程图，不断的规避可能存在的风险隐患。
换位思考能力，每一句账号体系的话术，每一个客诉问题隐藏的用户需求，都是深挖提升的地方。必须将自己幻化成遇到问题的用户，才能找到更合理更安全的解决路径。
一个产品该如何识别自己的用户？哪些场景要求用户登录或者注册？注册需要哪些信息？用户登录需要校验哪些信息？在互联网产品长期发展中，很多问题大家也基本总结出了标准化的方案。这期主要是围绕这些问题，盘点登录注册流程的各种功能以及其应用场景。
1. 一个产品该如何识别自己的用户？
这个问题比较宽泛，其实要识别用户主要分类为两种场景：登录前，登录后。
登录前
大部分产品登录前是可以使用很多功能的，这里就存在一个用户识别的问题，解决方案主要是取决于用户使用的平台。
如果使用的是浏览器，主要的方法是通过cookie。如果是移动设备，则可以使用设备ID，比如Android的device ID，iOS的IDFA。当然，如果是微信平台，也可以使用微信的OpenID。
登录后
登录后识别用户的方式也有多种，比如使用的第三方账号ID，比如使用注册手机号，比如使用注册的邮箱。
但是，最一般也是最推崇的做法是：使用自己的一个user ID。同时，所有的产品功能如果需要识别用户身份，也都应该用user ID进行识别；手机号、注册邮箱、第三方账号等其他关联信息，都应该可以和这个user ID进行关联。这样能最大程度保证账号体系的稳定性和扩展性。
2. 哪些场景下要求用户登录或者注册？
要求用户在使用产品前注册或者登录，是最简单粗暴的方法，但是这里可能对用户增长有很大的影响。所以对于用户认知没那么高的产品，一般而言，不会要求用户立即注册或者只是要求简单的注册。
把注册流程或者补充注册信息的内容，后置到一些关键节点，是更明智的做法。
比如：
典型的做法，比如电商，点击购物车结算才会要求用户登录注册，这样的方式更能留住用户，而不是在使用产品之前就流失。
3. 注册需要哪些信息？
3.1 可验证的外部账号验证
比如手机号、邮箱这些个人通讯账号，或者有通讯账号属性的社交网络账号，比如QQ号，微信号，微博账号。
一般而言，这些账号的特点是：可进行验证性。比如邮箱、手机的验证码，微信QQ、微博账号的授权登录。
可验证性的本质有两点：
可以验证用户身份的有效性
可以在密码丢失的情况下找回密码
当然，为了最大程度保证账号安全，这个外部账号最好可以是手机号。
3.2 用户名和密码
填写用户名和密码是用户注册一个传统的方式。但是这个方式目前也存在很多问题，比如被撞库。
现在有些产品已经在尝试去掉这个环节。一方面是为了简化注册流程，增加注册转化。另一方面，移动时代，APP基本可以一次登录一直用，登录情况比较少，完全可以用手机号验证码登录，或者三方登录进行。
3.3 注册验证码
注册验证码是为了防止机器大量刷注册量，尤其是部分注册不需要填写手机号的产品。可以使用图形验证码，也可以使用比较简单的用户行为验证码（需要了解验证码，可以查看上期内容）。
4. 用户登录需要校验哪些信息？
这个也是和用户使用的登录方式有关，根据用户登录的方式，一般分类为一下几种：
账号密码登录有极大的撞库风险。一般而言，用户只用一个手机号，使用这个手机号在各种产品上进行注册。而有大量的用户使用相同或者相似的密码，一旦有产品安全漏洞，密码泄露，其他平台则可以被撞库登录。
第三方账号也存在相同的风险，一旦第三方账号密码被他人获取，则可以轻易登录网站。
所以，如果是账号密码登录，第三方账号登录，存在异常登录情况，则需要进行安全信息的验证。
5. 异常登录判定和安全信息验证
异常登录的判定也是一个相对比较复杂的过程，基本上对于大的公司，比如阿里，是一个大的团队在做。
简单来说，收集用户登录的各种行为进行校验。包括但不限于：
校验既可以是简单粗暴的给策略，也可以是用大量的数据样本进行机器学习，进行判定。
安全信息验证部分，如果用户绑定了手机号（手机号相关内容可以查看上篇），则可以直接要求用户进行手机验证。
如果用户没有绑定手机或者用户暂时不方便使用手机，则可以使用图形验证码或者用户行为验证码验证。或者也可以使用产品的信息进行验证，包括但不限于：
当然，如果用户都不能通过自动流程，也可以进行人验证，提供一些无法格式化提供的信息进行验证。
6. 小结
登录注册流程是很多初级产品经理书籍里面经常提到的Case，比如交互的书就会说按钮怎么调整，注册率上升了多少个点之类。
然而，这些流程其实只是一小部分。基本上，在之前产品设计不犯错的情况下，也不会有一个按钮调整上升多少个点之类的传奇。
此篇文章没有讨论登录注册交互层的东西，更多的是对于登录注册逻辑的总结讨论，牵扯到很多异常的Case。
产品经理的初级阶段可能只能看到几个简单页面的调整，其实合格的产品经理更应该是看到页面的逻辑，以及因为逻辑而派生出来的更多页面。登录注册流程正是这样看似简单，实则牵扯很多复杂逻辑和异常Case的流程。
如果非要有什么拔高性的结尾，那么我想说的是：不要以为只沉迷在书上那些摆放按钮的故事中，就可以做好一个产品。
从互联网行业出现自动化工具开始，验证码就作为对抗这些自动化尝试的主要手段登场了，在羊毛党，扫号情况层出不穷的今天，验证码服务的水平也直接决定一家互联网企业的安全系数。作为WEB看门人，它不仅仅要做到安全，也要兼顾体验。
本文将分享携程信息业务安全团队在这几年里，对图形验证码服务所做的一些大大小小的改变。各位可以将本文作为自身网站图形验证码搭建的小攻略，减少重复踩坑的情况。
1.0时代
过去携程曾经使用了一套基于.NET的图形验证码作为控制登录，注册，发送手机短信，点评，重置密码以及其他相关场景的主要手段，目的也很简单，就是防止非实人的请求。
在这个阶段，设计时仅仅是满足了防御异常请求，并没有考虑太多用户体验以及产品上线后，运营数据收集再分析改造的需求。
主要实现的功能点为：
验证码图示：
流程图如图所示：
事后来看，这套验证码系统由于架构简单，接入简便，在很长一段时间内，担当了携程门户主要的看门人的角色，尽管各大BU并不是非常情愿地使用了这套服务，但是在防范撞库，恶意请求短信，批量获取优惠卷等场景下，还是体现出了一个验证码服务所应该起到的作用。
当时这套验证码服务上线后，遇到了不少的问题：
1、服务并没有对接入方做场景，事务等区别，整个携程的验证码难度都是统一的（除了部分BU自己开发了验证码），经常发生在A页面出现被扫号情况，需要增强验证码难度，但是B页面随之反馈，验证码太难，收到用户投诉，需要降低难度，无法兼顾。
2、服务记录的字段仅仅能支撑服务正常运行，业务数据没有进行记录。导致了验证码有时候调用和验证异常升高，完全无法知晓是谁在进行恶意尝试并进行拦截（比如封停恶意IP）。
3、只有英文数字，并且字体单一，设置的扭曲干扰线简单点，极易被OCR识别，假如设置的太难，就会造成连正常用户都无法识别的窘境，在很长的一段时间内，只能将难度设置在简单-中等这种难度，谈不上对于批量OCR有任何的防御。
而说到这类验证码的破解，业内目前通用的方案，我了解下来有这么几种：
1、通过各种手段，绕过风控，或者绕过验证码，比如某些验证码是本地校验，有些验证码的关键参数会下发至前端，用户可以修改参数达到控制验证码的目的，有些业务方接入了验证码，但是没有把校验和业务接口绑在一起，导致人家可以直接请求业务接口，验证码形同虚设。也有业务方在接入验证码的时候，登录动作先于验证码校验，也导致了验证码毫无意义。这些在过往的接入过程中，都是实际发生过的情况。
2、ORC，从二值化，去除干扰线/点，确定字体区域，到最后识别，会根据验证码本身难度的不同，显著的影响其识别率。
3、人工打码平台。目前打码平台针对图片验证码已经很成熟了，针对数字，英文，汉字，智能问答都有不同的价格。
4、CNN神经网络识别。通过大量的样本进行机器学习，对于某些OCR比较难识别的粘连字符字体，可能会有一个较好的识别结果。
随着各类攻击越来越多，穿透性也日益增强，业务部门对于验证码难度需求不一致，以及自身对于验证码数据收集再改造的这些情况下，改造这个服务已经成为了摆在眼前的事情。
1.5时代
在总结了上述提到的这些问题以后，新需求就自然而然的产生了：
在产品开发测试的一轮轮投入后，新的需求完成了，并且又花了将近一年的时间推广了各个BU接入了这个新的验证码。
（在这里说一个实际的情况，就是在第一版验证码开发的时候，并不重视保留接入方的信息，导致了在进行第二轮验证码重新接入的时候，发现老的接入方有3位数，但是要找谁，完全不清楚，以至于有些验证码到目前都没有进行更新，这个服务接入注册其实是一个很小的功能，但是在版本更迭，重大事务通知上，能起到非常重要的作用）。
新版本验证码比较好的解决了下面这几个实际场景面对的问题：
1、再也不会出现某个应用发现异常请求，刚刚调高难度没多久，就接到投诉电话，需要把难度降低这种场景，可以根据各自应用手动或者自动调节难度。（原先是整个公司都是统一的难度耦合在了一起）。
2、可以知道威胁是来自于哪个IP或者设备的，针对性的做出响应，比如封停请求。
3、在面对扫号配合OCR工具的情况下，这套验证码会自动不停的变换难度，干扰点/线，字体，背景色，粘连度等，经过实际对比观察，防御效果比老版本提高了2倍，这里我们的策略分为全局难度提高和针对纬度进行提高，比如假设只有一个IP或者设备的验证码请求发现异常，我们只会提高来自于这个IP或设备请求的验证码难度，对于其他正常请求是无感知的，但是在某些情况下，比如大规模的分布式扫号，可能你需要使用的就是全局难度提高。
4、支持了中文验证码，实际测试，英文数字在成熟的OCR工具面前，哪怕做了混淆，解析成功率也接近50%，假设换成中文配合一定的混淆，解析成功率一般不高于20%，这也是很多团队初期，假设没有风控和其他的辅助服务，最直接，成本最低的提高防御力度的方案。
这套方案，作为主流的验证码方案在携程应用了很久，但是在去年，团队也终于意识到，还有很多问题是这套验证码方案所无法解决的：
1、用户的体验问题，这个问题被公司内部诟病很久，并偶尔会收到来自于外部用户的投诉。其实也很好理解，一个四个字的随机中文验证码，手机输入一次大约耗时15-20秒，这个在活动营销拉新场景下，是一个致命的转化率杀手。在很多力度不是非常大的活动面前，这个验证码会直接打消一部分正常用户去尝试的念头（尽管中文验证码在防御恶意请求接口上有着巨大的安全优势），作为业务方产品不得不考虑，假设恶意用户的比例是5%，牺牲剩下95%用户的体验是否值得，即便也只有5%的正常用户放弃了尝试（比如一些年纪大的客户），和恶意用户的比例相仿，但是剩下的用户还是需要输入这些验证码，在用户体验成本上的让步是巨大的，这样就会让安全和业务陷入一种零和博弈的局面，这往往也是安全部门不受欢迎的主要原因。
2、接入繁琐，验证码和风控作为2个服务，需要业务方去耦合，分别接入，听起来就很繁琐，实际接入也确实很繁琐，大量的时间花费在接入服务上。
3、无法应对国际化，中文验证码国外用户不认识，英文数字过于简单压根没办法防御主流扫号攻击。实际发生过的案例就是携程海外站点被大规模扫号，但是束手无策的局面，分布式IP和设备，无法采用中文，几万个IP手动封不谈累不累，CFX都装不下，只能看着他扫。
4、丑，验证码图片由于需要防破解的关系，往往和整体页面UI的风格完全没有一个搭配感，让人很出戏。
和各大竞品比起来，我们的验证码确实就像是石器时代在和工业时代比较，也被公司内部一次次吐槽实在太影响体验了。在这种内忧外患的局面下，验证码服务更新又一次被放到了台面上。
2.0时代
需求又一次的被明确：
又是一轮一轮的测试开发，大约在半年前，完成了本次验证码重构的第一版，他主要实现了如下功能：
1、体验问题被解决了，在对比多种竞品以后，我们采取的方案为“滑块+选字”，在安全认为请求有风险的情况下，会出现滑块，假设在你滑动滑块期间采集的数据不足以认为请求是可信的情况下，会出现选字或者直接禁止请求访问，根据实际数据，用户滑动滑块的时间耗时一般平均在0.5秒一次，仅有很少的一部分用户会出现选字，选字一般的耗时在7秒左右，平均下来，整体耗时目前在携程实践下来，在1.7秒左右。
2、接入问题也得到了改进，业务方目前接入仅仅需要在页面上引入一个JS（APP为一个SDK），然后在监听到JS的一个事件提示，可以获取token后，获取token，由业务方服务端获取token以后到安全这里的校验服务校验，校验完成以后，整个流程就结束了，中间的判断风险，出现滑块，滑块校验，出现选字，选字校验这些步骤业务方都无需干涉以及传送数据，安全已经把后端的风控，风险仓库和验证码前端全部打通，业务方在无感知的情况下，相当于接入及使用了3个服务。
3、国际化问题，目前已经支持东南亚多国语言的选字和提示语服务，常用国家再也不会有无法看懂和无法输入的诟病。
新版验证码服务如图所示：
流程图如图：
这个版本作为目前携程验证码的主流应用版本，将在各个场景下代替过去的填字验证码，在体验和安全性上，大幅度超越之前的服务。
按照目前携程的每日验证情况来计算，新验证码对比老验证码能每天给用户节约500小时的验证时间。
填字验证码在H5端，通过大量实践，在保证安全性的前提下，输入正确率一般在88%-90%，存在了一个天花板，在新验证码上线后，整体通过率已经提高到了96%，接近了我们认为的实际异常比例。
同时我们对于前端采集的大量数据做了模型训练，对于某些规则难以发现的问题，会采用模型的结果来进行处理。
在某些公共登录注册场景下，我们会采用BI画像+特定活动物料的模式，给特定的用户进行验证码渠道的推广服务，如图：
但是这套服务，也存在一定的问题：
1、滑块服务存在被破解的可能，据一些外部专业测试机构报告，目前外部主流的一些SAAS滑块服务，被破解的概率在60%（他能让滑块认为他是安全的请求，选字就不会出现了）
2、选字的OCR识别依然存在，虽然存在要识别两套并点选的难度，但是有些外部专业团队已经实现了一定程度的破解。
3、体验上，在IOS系统，滑块容易造成页面的回退，对于一些指甲长的用户尤其容易造成这个问题，目前的解决方案只能是加大滑动条的大小，尽量远离屏幕边缘。
结语
没有一种验证码可以通吃所有场景，也没有绝对安全无法破解的验证码，只有在业务和安全不停权衡的前提下，找到一个属于体验和安全平衡的点，这才是验证码正确的打开方式。在和各种黑产团队不停斗争的过程中，验证码服务只有不停的改变，创新，才可以适应当前复杂的黑产现状以及业务多变的场景。
