首先密码找回程序是和注册及校验模式在一起的一个整体，要统筹进行设计。因为在用户丢失密码后，能在线上证明（线下是另一种情况）他是自己的只能通过他在注册及业务办理过程中预留的信息进行校验。

其次在使用某些技术保证找回密码的是本人，肯定要通过一些方法来让这些技术正确的生效。防止被非法分子利用。
用户凭证暴力破解：这个一般通过3次锁死，只能通过人工或者更加复杂的方法，等方式可以解决。
Token 信息暴露了用户身份：这个需要设计更加安全性的Token。
找回凭证有效性：不论凭证是预留问题，短信还是邮箱都要验证其有效性，以及实用情况。为了保证正确性可以多重验证同时使用。
还有就是操作的时候通过各种人机校验技术（CAPTCHA）对操作的对象进行判断，防止使用程序进行撞库。

其实密码找回这个业务的流程跟要求本身就存在一个安全性与方便性的矛盾。
最安全的做法肯定是让本人持有效证件、证明及办理时的手机来业务办理处进行人工验证。其实这也就是现在很多银行办理密码修改的要求，不过因为太麻烦了，所以一般网站很难做到。所以现在网站一般的密码找回流程都是一个安全性和方便性妥协的产物，求得在风险与方便之间的一个平衡点。这个平衡点的位置是与网站业务的类型有关，比如支付宝的实名验证及密码找回就比一般的网站难得多。

当然在新技术不断发展的时候，也会不断的有新的方便的验证技术出现，找回密码这个业务肯定也会不断的发展，变得更加安全及方便。比如现在的刷脸支付，只要人脸识别及活体检验技术过关，都能直接通过刷脸进行支付及办理业务了，那么又有什么不可以用来找回密码呢？

可以的话，来个帽衫吧。

1 用户凭证暴力破解：密码设计的是4位或6位的，会被黑客以爆破工具跑数据字典进行破解。
登陆提供安全防护，防止刷库撞库暴力破解、可疑登陆。

2 Token 信息暴露了用户身份：开发在设计找回密码的token时，使用了简单的对用户名进行md5运算作为token，导致只需要获取到用户名就能够生成找回密码的链接而重置任意用户的密码。
阿里云不是有安全产品“数据风控”嘛，用起来不就是了。

3 找回凭证有效性：由于找回凭证是短信验证码，没有做过多的校验，导致在后续的判断中，出现了问题，只验证了数据是否准确，未验证数据是否已经被使用过、数据是否绑定在特定账户上。导致验证数据被其他账户使用。
短信验证不都是有时效的嘛。
验明正身可以不局限在密码一途，我弱弱问一句，刷脸、指纹、声纹等等可以吗？

用户凭证暴力破解：
这个就是同个用户做次数限制了，还是相对简单的。
但有一个问题就是别人恶意操作后，如何不影响真实的用户？
比如判断常用IP或设备，再有就是真实用户能收到提醒，加强安全意识。
Token 信息暴露了用户身份：
Token应该是和用户信息完全无关的吧，有关系的话肯定也要加盐的，防止彩虹表攻击。
找回凭证有效性：
前几天刚发的话题 平时用于内测的短信接口，一夜狂发上万条！我该怎么办？ ,应用设计的是没有密码的，注册与登录都是手机验证码，刚开始的时候就是SessionID是统一的，没有任何安全设计，就产生了一个问题，你用手机号获取验证码，用B手机号还能登录；
所以后来加了一个解决方法：SessionID+手机号，只要手机号改变，就取不到Session。

像手机验证码、指纹这种，个人感觉对抗线下的暴力攻击完全无效，而刷脸这种就很好了，加入对表情、GPS定位及身边事物的检测，非常有助于解决问题。

从市面上大部分的软件、网站和APP来看，最常用的做法是，通过短信验证。首先是提供用户名，然后根据用户名需要匹配注册时使用的手机号。为了防止通过试错或者暴力破解的方式来找回密码，基本上会设置试错的次数，次数在3到5次，之后的错误就提示“请明天再试”。同时，为防止重复发送短信给服务器带来的压力，可以设置验证码一段时间内有效，比如10分钟内有效。
这样应该能抵御大部分的问题吧。我这方面做的也不多。欢迎其他人指正。

找回密码起初是用邮箱验证的，然后手机卡实名验证后就采用了短信验证。
虚拟号码开放之后，淘宝商家就有了虚拟号码验证码。
实名手机号开放验证码之后理论上确认为本人操作。
以前QQ号码被盗，但是又忘记的验证问题，只好拨打腾讯科技客服。
为了摆脱短信验证的短板，又有了语音验证。就是平台拨打你的手机，语音播报验证码，感觉这样的验证有效性更高。
现在很多验证码为了防止机器人操作，还需要拖动滑块，识图片。限制密码和验证码输入次数，超出自动关闭，只能拨打人工客服。这样增加了用户和平台数据安全性。其实钉钉微应用的免登陆token做得很好，有一系列的验证环节。
如果有人脸识别的应用，找回密码或者验证身份更加简单多了，只需要人脸识别一波，每个人的体征数据都不同。

我觉得使用短信验证码算是非常好的办法了。
找回密码这种功能最重要的点就是：
要确定是不是本人操作的。

要确定是不是本人操作的，还有比短信验证码更好的办法吗？手机是贴身携带的东西，见手机如见本人。而且手机短信时效性极好，正所谓天下武功唯快不破。邮件太慢了，而且不方便。

以上是凑字数的话。并没有在回答问题，题主问的是会有哪些问题以及怎么解决的。

下面正式开始（继续凑字数）。看，不用复制粘贴也可以做到哦。

有一个非常严重的问题，找回密码是必须使用以前绑定的手机号或邮箱。
假如以前的手机号不用了，而且忘记解绑了。那对不起，找人工客服吧。
如果是我，我会给他几个input框：

• 请输入新的手机号 ，
• 请输入旧的手机号 ，
• 您的家乡是？
• 您还能提供其他材料证明是您本人在操作吗？
• 一个验证码，确定不是机器人在操作

总之多看看大网站是怎么做的。比如学学QQ的密码找回功能。

网站的「密码找回」操作都隐藏着哪些问题？你是如何解决的呢？
自行开发自然问题多多，还是拿来主义比较好，简单方便快捷。互联网和开源软件是开发利器。

作为网络安全从业人员，我有话说。
关于作者提出的第一个弊端，这本身就是安全性和易用性之间的一个矛盾，4位或者6位纯数字输入方便，现在一般的做法就是同一ip重复提交多次后就要强制输入验证码，再结合验证码的有效期，假设攻击者采用变换代理的方式进行分段提交，设计一个提交上限也是未尝不可的。
第二种情况也很常见，很多众测平台关于登录的逻辑漏洞都是屡见不鲜，不仅仅是重置用户密码，更换令牌导致伪造任意用户登录同样可以利用，一般来说在逻辑和算法上优化，这样的模糊测试根本就是徒劳无功。
第三种情况倒是有可能发生，笔者的意思是我注册的账户用密码找回获取的短信验证码可以同时利用到其他账户重置密码么？首先有人提到了时效性，其次大部分的网站设计都是输入手机号以及比对对应字段关系，这种类型的错误倒是不常见。
重置任意用户密码的案例和利用方式有很多，曾经检测一个大型医疗企业，输入用户id后在返回表单里隐藏了邮件地址，修改后可重置任意用户密码。当然作为攻击者来说，除了爆破及撞库去获取用户密码外，修改用户密码也是常见攻击方式之一。
现在的网站和应用在重置密码以及登录上，大多采用发送短信验证码的方式，假设运营商的短信数据如果被获取，那么采用多么复杂的验证码或者设置时效性，都是无法防范的。总之攻防就是对立的，哪怕是生物识别也未必安全，建立有效的互信体系，才是网络安全的发展前提。

短信验证码就行，别的没什么用

1. 密码要求6位以上的，数字，大小写，特殊字符都要，用密码字典破解可以尝试破解
2. 找回密码可以分为邮箱和手机验证码，验证码和用户发送的账号是绑定的，同时和当时用户的IP也是绑定的
3. 找回密码的时候，对于一个账户，每天连续5次验证码输入出现问题，则找回密码方式中其中一个不可用，比如你用手机验证码找回时，验证码输入几次都是错误的，那今天手机验证码找回方式就不可用，只能通过邮箱，如果邮箱的方式也不可用了，最后只能联系客服，提供一堆资料验证你的信息，然后你懂的

说下我的处理流程
首先是校验用户名是否合法/存在

1.前端js校验 避免提交错误的账号数据，减小server端压力，同时也提醒用户账号输入错误。
2.server端再次进行账号格式校验 如果校验失败，则说明是有人绕过了前端校验，可以拒绝服务，同时记录该IP和相关信息。为后续处理做好数据准备。
3.server校验账号是否存在 如果账号存在则发送手机验证码，如果账号不存在利用IP地址或者session记录账号错误次数。超过一定次数后拒绝服务。在DB中，专门设置一个表记录这种异常如：

如果尝试次数超过了10次，我会把这个IP记录到异常IP库中。以便日后结合网站日志分析该IP的具体情况。当然这张表只能粗略监测异常IP，但是针对一些恶意用户的识别率还是很高的。
至此，在用户名格式校验，用户名校验中已经初步识别了跨站和穷举两种攻击。
其次是验证码校验
这里主要防止验证码被暴力破解

1. 前端js校验验证码格式 避免提交错误的验证码数据，减小server端压力，同时也提醒用户验证码输入错误。
2. server端校验验证码 这是最关键的一步，详细流程如下：
   2-1. server端接收数据后 首先应该判断数据来源，比如是不是来自post的数据，是不是来自站外提交的数据。如果不能保证数据来源的可靠性，就拒绝服务，并记录IP。

2-2. server端校验验证码是否正确 验证码校验失败则记录一次（用手机号码作为身份标记）

如上，tel为1506999336的用户尝试了多次验证码，都失败了，这是很不正常的现象。所以这种异常应该记录到IP库，并且锁定tel为1506999336的用户账号。
如果校验成成，则进入下一步，校验验证码的时效性。
2-3. 验证码时效性校验 校验失败的返回提示信息，重新发送。校验成功的开始设置新密码。并删除数据库中所有失效的验证码。
最后是密码的重设
重设密码这一步也有个很大的坑，就是一定要防止用户A通过了验证码验证后，为用户B设置密码的情况。前面各位都已做很好的描述我就不扯扯了。
我想说的一点的是，不同的项目需求应该有着不同的设计理念。如果非常强调用户安全，则还需要引入密码保护等手段。仅仅靠验证码不一定能起到也有的作用。
在前面看到有专家提到IP地址会变，并且还可以隐藏真实IP。所以记录IP地址，只能作为一个辅助的手段。

开发过程中遇到忘记密码这种的, 个人是这样解决的:

在注册时 绑定的是手机号码, 忘记密码是通过 先填写账号(账号不是电话号码), 发送短信（账号注册的时候绑定的手机号码） 验证码, 然后跳转到修改密码。

如果遇到忘记密码, 旧的手机号码不用的情况, 会让先输入 先绑定的 旧的手机号, 然后新的手机号, 然后输入注册的时候绑定的第三的账号。然后获取短信验证码 跳转修改密码

限定了修改密码次数和输入旧账号次数

个人想法, 为了更安全,可以对用户行为作出分析, 然后 生成特定问题, 让回答。比如经常浏览 的栏目排序选择顺序, 或者是 登录时段, 等问题,

短信验证码已经做的比较完善了，但是有些时候绑定手机号可能不再使用，可能会被其他人所获取秘密，可以采用多方面验证的方式，比如特殊情况使用人脸识别等

首先密码找回程序是和注册及校验模式在一起的一个整体，要统筹进行设计。因为在用户丢失密码后，能在线上证明（线下是另一种情况）他是自己的只能通过他在注册及业务办理过程中预留的信息进行校验。
其次在使用某些技术保证找回密码的是本人，肯定要通过一些方法来让这些技术正确的生效。防止被非法分子利用。
用户凭证暴力破解：这个一般通过3次锁死，只能通过人工或者更加复杂的方法，等方式可以解决。
Token 信息暴露了用户身份：这个需要设计更加安全性的Token。
找回凭证有效性：不论凭证是预留问题，短信还是邮箱都要验证其有效性，以及实用情况。为了保证正确性可以多重验证同时使用。
还有就是操作的时候通过各种人机校验技术（CAPTCHA）对操作的对象进行判断，防止使用程序进行撞库。
其实密码找回这个业务的流程跟要求本身就存在一个安全性与方便性的矛盾。
最安全的做法肯定是让本人持有效证件、证明及办理时的手机来业务办理处进行人工验证。其实这也就是现在很多银行办理密码修改的要求，不过因为太麻烦了，所以一般网站很难做到。所以现在网站一般的密码找回流程都是一个安全性和方便性妥协的产物，求得在风险与方便之间的一个平衡点。这个平衡点的位置是与网站业务的类型有关，比如支付宝的实名验证及密码找回就比一般的网站难得多。
当然在新技术不断发展的时候，也会不断的有新的方便的验证技术出现，找回密码这个业务肯定也会不断的发展，变得更加安全及方便。比如现在的刷脸支付，只要人脸识别及活体检验技术过关，都能直接通过刷脸进行支付及办理业务了，那么又有什么不可以用来找回密码呢？
可以的话，来个帽衫吧。

我觉得密码找回还是本人连线来个人脸活体视频问答这样比较可靠点。反正现在网络通讯这么发达，只要有手机就可以视频通话了。不存在说上不了网

关于保存密码的问题已经有了成熟的方案，那就是使用phpass

最好不要使用使用
1, 用户创建自己的账号  2, 用户密码经过hash操作之后存储在数据库中。没有任何明文的密码存储在服务器的硬盘上。  3, 用户登陆的时候，将用户输入的密码进行hash操作后与数据库里保存的密码hash值进行对比。  4, 如果hash值完全一样，则认为用户输入的密码是正确的。否则就认为用户输入了无效的密码。  5, 每次用户尝试登陆的时候就重复步骤3和步骤4。

原本很简单的东西大家就要搞的那么复杂

一定要做好用户的ID和账号的双重验证，如果用手机做验证 手机号在验证的时候必须做手机与验证码的验证，总之就是验证要双重，严查不可少，我没开发过，但我知道你不做验证我就能刷你点东西0.0.

短信认证，设置错误次数，超过次数就禁止继续刷了，短信认证使用过后就清除，不能重复使用。有能力的情况下可以人脸识别、指纹认证什么的。修改密码后给手机发送条信息通知密码修改了，降低他人修改风险。

手机防盗密码不知如何找回？
既没有短信验证，也没相关提示