作者记录了自己在进行产品安全设置模块改进过程中遇到的问题以及几点思考，分享给大家，希望对大家带来启发。

背景

笔者最近在处理所负责的产品的「安全设置」模块。我们的产品是 Web 端，最初是用邮箱作为登录主键的，之后转为将手机号作为第一主键，每位用户必须有手机号，而邮箱则成为了可选项。一直以来，我们的产品都只有「通过原密码改密」和「通过邮箱 / 手机号重设密码」这两个基础的改密功能，而不能修改手机号和邮箱，这已经被用户多次吐槽过了。

为什么这么基础的功能我们却一直都没有提供呢？

首要原因自然是开发力量有限，而无论是修改手机号、修改邮箱，甚至修改密码，都算是很低频的操作，与之前我们在进行的支付相关功能的开发相比，显然没有那么重要。

用户对「安全设置」的期望，大概有这三种，分别是：修改手机号、修改邮箱和修改密码。

为了满足这些需求，我们可以通过这样几种方式来达成：验证密码、验证手机号、验证邮箱和进行人工申诉。

实施过程所遇到的问题与看法

虽然作为一名产品经理，我曾体验过大大小小上百个产品，但说实话，改密和改帐号的流程，却从来都没有关注过，这时候自然要拿出作为产品人的第一把武器：抄！在抄的过程中，我想到了这些问题，并且给出了自己的看法。

Q1：通过验证原密码改密的方法为什么不可取？

观察一下现在各大厂的做法，通过原密码改密的方式已经稍显落后了。

对于我们的产品来说，若提供了通过原密码改密的功能，一旦用户密码被盗取，第一时间就会对账户的主人造成困扰，而邮箱、手机号则盗取的难度会相应更高一些。手机号的盗取难度自然不必说，而邮箱则又多了一层密码防护，并且即使被盗也未必会对用户在我们产品中的账户造成直接影响。因此，我在产品中并不会提供这个改密方式。

Q2：用户登录后，是否有必要提供改密功能？

这是在体验简书网站时发现的，登录简书后，简书并没有提供修改密码的功能（修改绑定邮箱和手机号的功能也没有）。讲道理，用户修改密码最大的可能性，就是忘记了密码，这时在登录后提供一个修改密码的功能显然是没有什么帮助的，除非——用户就是想改密码，但哪怕只是因为这一个「除非」，这个功能也还是需要做的。

Q3：绑定邮箱 / 手机号时，是否应通过已绑定的另一个途径进行验证？

这是必须的，否则，账户被盗取后依然很容易被改密——直接绑定盗号者的邮箱或手机号就可以了。出于这个考虑，绑定时的验证必须是已绑定的另一个途径，而不能是密码，否则也没有太大意义。

Q4：变更邮箱 / 手机号时，应当通过需要变更的途径进行验证，还是通过任意一种已绑定的途径进行验证？

后者。无论是手机号还是邮箱，一个人对其进行更换都不会非常频繁，而更换的原因主要是因为——无法找回了。例如，很典型的例子，一些大学会给学生统一办一批连号的手机卡，以便在学校中使用，当学生毕业后，来到另一个城市工作，多数会更换新的手机号，并注销掉学校的手机号，很少会有人一直保留之前的号码。在这个过程中，用户并不会把上一个手机号绑定的所有账户都换绑新号，在这个时候，我们必然应当允许用户通过进行邮箱验证来更换绑定的手机号。同理，在用户手机坏了、手机在外地丢失等场景下，这个功能也是有必要的。

Q5：为什么要屏蔽绑定邮箱 / 手机号中的部分字符？

A5：这是一个能给盗号者带来极大困扰，而一般不会影响到用户的措施。当盗号者盗取账户后，这个策略能够有效的保证盗号者不会通过明文的邮箱和手机号进行社工。特别是针对一些可以自定义登录账户（用户名）的网站会更有用。

Q6：人工申诉时，如何判断申诉者是用户本人？

人工申诉一般是针对其他途径均无法找回密码时使用的。我们的产品是可以进行上传身份证进行身份验证的，因此我们可以通过要求用户提供身份证后 6 位的形式来进行验证；如果用户在我们的网站上进行过购买，我们也可以要求其出具具体的购买时间及订单号；比较通用的，还可以要求用户提供曾用密码（但很少会有产品记录这个）。

其实在思考这些问题的时候，我的心里就已经有了方案了，而且思考的焦点也没有只盯在自己的产品上。在设计产品的过程中，我们思考的越多，策略就会越复杂，当然也就会越安全，而安全和便捷无法兼得，为了安全，就必然会牺牲一部分用户体验，但这都是值得的。

本文由 @青晖 原创发布于人人都是产品经理。未经许可，禁止转载。