5种密码找回设计
当用户忘记密码时，通常都要使用找回密码、重置密码功能。找回密码并不是真正地将原来的密码告诉用户，因为这个密码在数据库中的存储也是加密的，根本无法获取到原始的明文密码是什么。
找回密码的本质是根据用户现有的信息做比对，来进行身份核实。核实通过之后允许用户进行密码修改，进而达到找回密码的目的。
用户可以采用哪种方式找回密码，完全与系统所持有的用户信息完整度相关。例如，用户根本没有绑定手机号和邮箱，则无法通过手机号或邮箱找回密码。同时，密码修改是一项十分敏感的操作，必须保证整个流程的绝对安全。
1.密保问题类找回密码设计
利用密保问题来找回密码是最为简单的设计，注册时进行问题和答案的采集，这些问题有系统预先设置的，也有用户自己设置的。例如，“您父亲的姓名？”“您母亲的姓名？”“您小学的名称？”等。
密保找回密码流程如图5-11所示，包含以下6个步骤。
（1） 用户进行注册，填写密保问题和答案。
（2） 将用户所选的题目和答案进行存储。
（3） 当用户找回密码时，要求先输入用户名。
（4） 根据用户名从数据库拉取密保问题，并要求用户回答。（5）比对用户当前提交的答案与注册时填写的答案。
（6）如果答案正确，则进入密码修改环节。
图5-11 密保找回密码流程
密保问题很容易泄露，如父母、配偶、学校、生日等信息是很容易被获取的。如果用户自己设置密保问题，则又很容易遗忘。
一旦密保问题无法回答正确，又没有其他密码找回手段，就只能通过人工申诉进行找回，十分不便。因此，密保问题类找回密码设计已经渐渐地废弃不用了，或者只是作为找回密码的备用手段。
2.下行短信验证码找回密码设计
首先要理解上行短信和下行短信的概念。上行短信是指用户主动给运营方发送的短信，如用户主动给10086发送的短信。下行短信是指运营方主动给用户发送的短信，如淘宝给用户发送了一条“双11”促销短信。下行短信验证码的方式是现在大多数系统所采用的设计。
下行短信验证码找回密码流程如图5-12所示，流程短，体验好，是现在最主流的设计方式，前提条件也很简单，系统必须提供手机号注册或绑定功能。通常只有4个步骤，即录入手机号、获取验证码、填写验证码和修改密码。
图5-12 下行短信验证码找回密码流程
然而，此流程也存在安全隐患，可以引入Token的多重校验机制，避免验证码被窃取。
下行短信验证码找回密码的安全流程如图5-13所示，包含以下11个步骤。
（1） 用户进入找回密码流程，输入手机号。
（2） 客户端向服务端发送请求，获取短信验证码。
（3） 服务端校验手机号是否存在，如果存在，则向用户手机发送短信验证码。
（4） 服务端生成Token并返回给客户端，目的是将验证码、手机号、Token绑定，增加安全校验，这一步也是被大多数设计者经常忽略的一步。
（5） 用户将接收到的短信验证码录入页面中，点击“提交”按钮，客户端携带用户录入的验证码及Token请求服务端。
（6） 服务端校验用户提交的验证码与Token所对应的验证码是否匹配并且有效。
（7） 服务端返回客户端验证成功，客户端跳转到修改密码页面。
（8） 用户录入要修改的新密码，点击“提交”按钮。
（9） 客户端携带手机号、新密码、Token、短信验证码请求后端修改密码。这一步也经常被忽略，如果只将新密码发送给了后端来执行修改操作，则有巨大的安全隐患。
（10） 服务端验证手机号、Token、短信验证码全部匹配并且有效，才会执行修改操作。
（11） 返回修改结果（成功、失败）。
图5-13 下行短信验证码找回密码的安全流程
思考1：如果没有Token机制，会有什么危险？例如，在你的手机上植入木马读取短信内容，一旦获取到验证码就可以直接在其他地方使用，而与具体的执行环境无关。然而，对方无法同时获取短信和
Token，从而保证了即使短信验证码被盗取，也无法使用。
思考2：如果不增加Token、手机号、验证码的校验，则可以通过模拟请求的方式来随意修改密码。思考3：验证码的特点是有效期短，使用一次立即失效，并且只对单一业务有效。在密码修改功能中获取了一个验证码，则只能在这个业务功能使用，而不能在转账付款功能中使用。很多人将获取验证码、校验验证码的功能作为统一服务，而忘记了增加业务隔离限制，就会导致验证码可以重复使用。
统一的短信验证码服务接口，必须包含Token和验证码类型两个字段，如表5-4所示。
表5-4 统一验证码服务接口字段设计
这样，在请求验证码获取接口时，只要传入不同的验证码类型，就可以得到不同类型的验证码了。其中1、2、3用户可以在非登录状态下获取，而4、5、6用户必须在登录状态下才能获取。为了防止验证码接口被攻击，一般还要在业务流程中加入图片、文字验证码环节。
3.上行短信验证码找回密码设计
上行短信验证码的方式一般在使用账号找回密码的场景中使用，用户使用注册手机或绑定手机向指定的运营商号码发送指定内容，完成验证。
上行短信验证码找回密码流程如图5-14所示，包含以下9个步骤。
（1） 用户录入要找回密码的账号，点击“确定”按钮。
（2） 将账号提交到服务端。
（3） 服务端使用账号查询账号锁绑定的手机号。（4）脱敏后返回给客户端，脱敏就是以18*****3052这种形式返回，避免用户的敏感信息被窃取。
（5） 提示用户以下信息，如“请使用18*****3052号码给
123456789运营商号码发送短信，短信内容为czmm”，czmm为指令，代表重置密码（指令可以由服务端随意指定）。
（6） 用户使用该手机号发送指定短信内容给短信运营商，短信运营商会将此信息转发给服务端系统，服务端系统进行发送方手机号、短信内容的验证。
（7） 用户发送完短信后，在页面上点击“我已发送”按钮，目的是通知服务端。
（8） 服务端验证是否接收到上行短信，并且验证手机号和短信内容是否全部正确，如果正确，则向客户端返回验证通过。
（9） 客户端接收到验证通过的消息后，跳转到修改密码页面，完成后续流程。
图5-14 上行短信验证码找回密码流程
上行短信验证码的方式可以有效防止短信接口被攻击，更加安全，但是会让用户操作更加烦琐，并且用户会产生短信费用，所以体验性有所下降。
思考：是否可以通过上行短信直接设置密码？
答案是肯定的。例如，可以发送 “姓名#身份证号#账号#新密码” 给服务端，直接通过信息比对，然后修改密码，这种方式虽然简单高效，但是短信遗失、被窃取的风险很高。一旦用户短信泄露，则账号将处于“裸奔”状态，因此这种设计应该尽量避免使用。
4.邮箱找回密码设计
邮箱找回密码也是一种常用设计，同样要求系统必须提供邮箱注册或绑定功能，否则无法利用邮箱找回。
邮箱找回密码流程如图5-15所示，包含以下9个步骤。
（1） 用户在客户端录入邮箱。
（2） 将邮箱地址提交给服务端。
（3） 服务端校验邮箱是否存在，如果存在，则生成Token串，
Token具有有效期，如1小时。同时，对邮箱地址进行哈希加密（使用
MD5、SHA等算法，防止邮箱地址被篡改）。
（4） 给用户邮箱发送邮件，邮件的内容为用户修改密码的地址，地址后面拼接Token和加密后的邮箱参数，如 https://xxx:xx/restPassword?
token=6wUU0Xwecav1TsFIiLwTS4wFaiLJtEvmrhwMIv
9VFQq5VX55fXjEOAJgeFFAYMqk&email=5B0mDIsukVgkp2AY36O9。
（5） 用户点击邮箱中的链接，跳转到客户端，进入密码修改页面。
（6） 用户录入新的密码，并提交。
（7） 客户端携带新密码、Token（从URL中获取）、加密后的邮箱地址提交到服务端。
（8） 服务端校验Token是否存在并且有效，邮箱是否匹配，如果校验通过，则执行修改操作。（9）服务端将修改结果返回给客户端。如果Token已经过期，则提示链接已失效；如果无法找到匹配的数据，则提示非法链接。
图5-15 邮箱找回密码流程
在这个设计中，最重要的就是Token和E-mail加密串的使用，避免了密码修改链接被篡改的风险。
5.人工申诉找回密码设计
人工申诉找回密码是一项十分重要，而又经常被忽略的设计。因为用户更换了手机号和邮箱，或者忘记了当时注册所使用的手机号和邮箱，导致无法找回密码。而系统上又没有任何人工申诉的入口和联系方式，就会导致用户陷入死循环。人工申诉找回密码可以使用在线客服、电话客服、邮箱客服，可以不开发任何功能，但是必须让用户需要时能够找到解决路径，这就是设计中的闭环思维。