如何打造资产类应用的安全验证

最近和同事一起负责一个项目的迭代，这是一个关于资产交易的软件，第一期的迭代中已经实现了最核心的功能内容，第二期的迭代重点放到了安全验证和KYC身份认证上。

首先是基础，我们应用的账号体系，我们支持用户使用手机号或者邮箱来注册，这是较为常见的实现方式。作为涉及资产及交易类的软件，仅仅简单的验证登录密码是不够安全的。因此我们增加支持了Google安全验证器的功能。

因此本文讨论的安全验证是基于：手机短信验证、邮箱验证和Google验证器三种类别之上的。

第一次分析了各种情况后给出的方案比较复杂，有一共八种不同的安全验证场景：

其中后四种都是使用场景非常单一的情况，这让我们发现了一个问题：

比如在手机注册的情况下开启Google，修改手机号时是否需要验证原手机的验证码？

如果验证，自然可以确保绝对安全，但是同时也舍弃了一种场景，用户原手机号已经不能正常使用的情况。

如果不验证，我们可以完美支持以上的场景，同时也提高了用户的使用体验，但是放弃了绝对安全性。

在做资产类应用的产品以来，我发现在安全与体验方面总是存在着非常强烈的博弈。这类应用的安全漏洞是非常危险的伤害，不仅仅是对应用本身，更是因为直接关系到资产，而用户体验部分又是我们不得不时刻关注的因素，甚至在整个的产品周期中，都是一贯到底不变的主体之一。这个时候两者之间的较量会让产品经理非常头疼，最终将在团队中选择不同程度的妥协，决策的过程往往会考虑以下几点：

产品所处的阶段

攻击产生的可能性

公司对于产品的阶段定位

对用户体验的影响面

最终，我们优化了第一次的方案，选择了不验证，当然这样的话，明显会有一个场景的缺失，那就是如果用户使用手机号注册，并且没有启用Google验证和邮箱验证，需要更改手机号的情况。针对这种情况我们将不允许用户修改手机号，而是需要用户在绑定另一个安全验证之后才可操作。

优化后的方案如下：