密码找回是几乎每一个涉及到账户系统都要做的功能,上到我们的银行卡密码找回,下到一个 App 的密码找回。不同的应用为我们提供了不同的密码找回的方式。这是一个看起来简单,但是真的仔细考究,可能会存在很大问题事情。
在这次的聚能聊中,我希望作为工程师的你,能够分享一些你在设计密码找回功能时遇到的问题和解决的方案。作为本次的聊主,我也会为你提供一些问题的参考和部分解决方案。毕竟,我一个人能遇见的问题太少了,还是希望大家能够一起来分享在设计这个功能时遇见的问题和对应解决方案。
....
其实还有很多问题,这里就不再一一讲解,把机会留给大家,欢迎大家来参与讨论,分享自己踩过的坑和如何解决对应的问题。老规矩,依然是你来分享,我来为你送上礼品!
阿里云代金券 x 5
云栖定制电脑包 x 2
云栖帽衫 x 1
北方的郎
已获得云栖帽衫
复制链接去分享
首先密码找回程序是和注册及校验模式在一起的一个整体,要统筹进行设计。因为在用户丢失密码后,能在线上证明(线下是另一种情况)他是自己的只能通过他在注册及业务办理过程中预留的信息进行校验。
其次在使用某些技术保证找回密码的是本人,肯定要通过一些方法来让这些技术正确的生效。防止被非法分子利用。
用户凭证暴力破解:这个一般通过3次锁死,只能通过人工或者更加复杂的方法,等方式可以解决。
Token 信息暴露了用户身份:这个需要设计更加安全性的Token。
找回凭证有效性:不论凭证是预留问题,短信还是邮箱都要验证其有效性,以及实用情况。为了保证正确性可以多重验证同时使用。
还有就是操作的时候通过各种人机校验技术(CAPTCHA)对操作的对象进行判断,防止使用程序进行撞库。
其实密码找回这个业务的流程跟要求本身就存在一个安全性与方便性的矛盾。
最安全的做法肯定是让本人持有效证件、证明及办理时的手机来业务办理处进行人工验证。其实这也就是现在很多银行办理密码修改的要求,不过因为太麻烦了,所以一般网站很难做到。所以现在网站一般的密码找回流程都是一个安全性和方便性妥协的产物,求得在风险与方便之间的一个平衡点。这个平衡点的位置是与网站业务的类型有关,比如支付宝的实名验证及密码找回就比一般的网站难得多。
当然在新技术不断发展的时候,也会不断的有新的方便的验证技术出现,找回密码这个业务肯定也会不断的发展,变得更加安全及方便。比如现在的刷脸支付,只要人脸识别及活体检验技术过关,都能直接通过刷脸进行支付及办理业务了,那么又有什么不可以用来找回密码呢?
可以的话,来个帽衫吧。
沙漠的热情
已获得阿里云代金券
复制链接去分享
1 用户凭证暴力破解:密码设计的是4位或6位的,会被黑客以爆破工具跑数据字典进行破解。
登陆提供安全防护,防止刷库撞库暴力破解、可疑登陆。
2 Token 信息暴露了用户身份:开发在设计找回密码的token时,使用了简单的对用户名进行md5运算作为token,导致只需要获取到用户名就能够生成找回密码的链接而重置任意用户的密码。
阿里云不是有安全产品“数据风控”嘛,用起来不就是了。
3 找回凭证有效性:由于找回凭证是短信验证码,没有做过多的校验,导致在后续的判断中,出现了问题,只验证了数据是否准确,未验证数据是否已经被使用过、数据是否绑定在特定账户上。导致验证数据被其他账户使用。
短信验证不都是有时效的嘛。
验明正身可以不局限在密码一途,我弱弱问一句,刷脸、指纹、声纹等等可以吗?
微wx笑
已获得阿里云代金券
复制链接去分享
用户凭证暴力破解:
这个就是同个用户做次数限制了,还是相对简单的。
但有一个问题就是别人恶意操作后,如何不影响真实的用户?
比如判断常用IP或设备,再有就是真实用户能收到提醒,加强安全意识。
Token 信息暴露了用户身份:
Token应该是和用户信息完全无关的吧,有关系的话肯定也要加盐的,防止彩虹表攻击。
找回凭证有效性:
前几天刚发的话题 平时用于内测的短信接口,一夜狂发上万条!我该怎么办? ,应用设计的是没有密码的,注册与登录都是手机验证码,刚开始的时候就是SessionID是统一的,没有任何安全设计,就产生了一个问题,你用手机号获取验证码,用B手机号还能登录;
所以后来加了一个解决方法:SessionID+手机号,只要手机号改变,就取不到Session。
像手机验证码、指纹这种,个人感觉对抗线下的暴力攻击完全无效,而刷脸这种就很好了,加入对表情、GPS定位及身边事物的检测,非常有助于解决问题。
饭娱咖啡
已获得云栖定制电脑包
复制链接去分享
从市面上大部分的软件、网站和APP来看,最常用的做法是,通过短信验证。首先是提供用户名,然后根据用户名需要匹配注册时使用的手机号。为了防止通过试错或者暴力破解的方式来找回密码,基本上会设置试错的次数,次数在3到5次,之后的错误就提示“请明天再试”。同时,为防止重复发送短信给服务器带来的压力,可以设置验证码一段时间内有效,比如10分钟内有效。
这样应该能抵御大部分的问题吧。我这方面做的也不多。欢迎其他人指正。
aoteman675
已获得阿里云代金券
复制链接去分享
找回密码起初是用邮箱验证的,然后手机卡实名验证后就采用了短信验证。
虚拟号码开放之后,淘宝商家就有了虚拟号码验证码。
实名手机号开放验证码之后理论上确认为本人操作。
以前QQ号码被盗,但是又忘记的验证问题,只好拨打腾讯科技客服。
为了摆脱短信验证的短板,又有了语音验证。就是平台拨打你的手机,语音播报验证码,感觉这样的验证有效性更高。
现在很多验证码为了防止机器人操作,还需要拖动滑块,识图片。限制密码和验证码输入次数,超出自动关闭,只能拨打人工客服。这样增加了用户和平台数据安全性。其实钉钉微应用的免登陆token做得很好,有一系列的验证环节。
如果有人脸识别的应用,找回密码或者验证身份更加简单多了,只需要人脸识别一波,每个人的体征数据都不同。
cjsoldier
已获得阿里云代金券
复制链接去分享
我觉得使用短信验证码算是非常好的办法了。
找回密码这种功能最重要的点就是:
要确定是不是本人操作的。
要确定是不是本人操作的,还有比短信验证码更好的办法吗?手机是贴身携带的东西,见手机如见本人。而且手机短信时效性极好,正所谓天下武功唯快不破。邮件太慢了,而且不方便。
以上是凑字数的话。并没有在回答问题,题主问的是会有哪些问题以及怎么解决的。
下面正式开始(继续凑字数)。看,不用复制粘贴也可以做到哦。
有一个非常严重的问题,找回密码是必须使用以前绑定的手机号或邮箱。
假如以前的手机号不用了,而且忘记解绑了。那对不起,找人工客服吧。
如果是我,我会给他几个input
框:
总之多看看大网站是怎么做的。比如学学QQ
的密码找回功能。
作为网络安全从业人员,我有话说。
关于作者提出的第一个弊端,这本身就是安全性和易用性之间的一个矛盾,4位或者6位纯数字输入方便,现在一般的做法就是同一ip重复提交多次后就要强制输入验证码,再结合验证码的有效期,假设攻击者采用变换代理的方式进行分段提交,设计一个提交上限也是未尝不可的。
第二种情况也很常见,很多众测平台关于登录的逻辑漏洞都是屡见不鲜,不仅仅是重置用户密码,更换令牌导致伪造任意用户登录同样可以利用,一般来说在逻辑和算法上优化,这样的模糊测试根本就是徒劳无功。
第三种情况倒是有可能发生,笔者的意思是我注册的账户用密码找回获取的短信验证码可以同时利用到其他账户重置密码么?首先有人提到了时效性,其次大部分的网站设计都是输入手机号以及比对对应字段关系,这种类型的错误倒是不常见。
重置任意用户密码的案例和利用方式有很多,曾经检测一个大型医疗企业,输入用户id后在返回表单里隐藏了邮件地址,修改后可重置任意用户密码。当然作为攻击者来说,除了爆破及撞库去获取用户密码外,修改用户密码也是常见攻击方式之一。
现在的网站和应用在重置密码以及登录上,大多采用发送短信验证码的方式,假设运营商的短信数据如果被获取,那么采用多么复杂的验证码或者设置时效性,都是无法防范的。总之攻防就是对立的,哪怕是生物识别也未必安全,建立有效的互信体系,才是网络安全的发展前提。
说下我的处理流程
首先是校验用户名是否合法/存在
1.前端js校验 避免提交错误的账号数据,减小server端压力,同时也提醒用户账号输入错误。
2.server端再次进行账号格式校验 如果校验失败,则说明是有人绕过了前端校验,可以拒绝服务,同时记录该IP和相关信息。为后续处理做好数据准备。
3.server校验账号是否存在 如果账号存在则发送手机验证码,如果账号不存在利用IP地址或者session记录账号错误次数。超过一定次数后拒绝服务。在DB中,专门设置一个表记录这种异常如:
id | IP | trytimes | lasttime |
---|---|---|---|
2012 | 10.0.0.1 | 6 | 2018-12-16 22:53:33 |
如果尝试次数超过了10次,我会把这个IP记录到异常IP库中。以便日后结合网站日志分析该IP的具体情况。当然这张表只能粗略监测异常IP,但是针对一些恶意用户的识别率还是很高的。
至此,在用户名格式校验,用户名校验中已经初步识别了跨站和穷举两种攻击。
其次是验证码校验
这里主要防止验证码被暴力破解
2-2. server端校验验证码是否正确 验证码校验失败则记录一次(用手机号码作为身份标记)
id | TEL | trytimes | lasttime |
---|---|---|---|
2012 | 1506999336* | 16 | 2018-12-16 22:53:33 |
如上,tel为1506999336的用户尝试了多次验证码,都失败了,这是很不正常的现象。所以这种异常应该记录到IP库,并且锁定tel为1506999336的用户账号。
如果校验成成,则进入下一步,校验验证码的时效性。
2-3. 验证码时效性校验 校验失败的返回提示信息,重新发送。校验成功的开始设置新密码。并删除数据库中所有失效的验证码。
最后是密码的重设
重设密码这一步也有个很大的坑,就是一定要防止用户A通过了验证码验证后,为用户B设置密码的情况。前面各位都已做很好的描述我就不扯扯了。
我想说的一点的是,不同的项目需求应该有着不同的设计理念。如果非常强调用户安全,则还需要引入密码保护等手段。仅仅靠验证码不一定能起到也有的作用。
在前面看到有专家提到IP地址会变,并且还可以隐藏真实IP。所以记录IP地址,只能作为一个辅助的手段。
首先密码找回程序是和注册及校验模式在一起的一个整体,要统筹进行设计。因为在用户丢失密码后,能在线上证明(线下是另一种情况)他是自己的只能通过他在注册及业务办理过程中预留的信息进行校验。
其次在使用某些技术保证找回密码的是本人,肯定要通过一些方法来让这些技术正确的生效。防止被非法分子利用。
用户凭证暴力破解:这个一般通过3次锁死,只能通过人工或者更加复杂的方法,等方式可以解决。
Token 信息暴露了用户身份:这个需要设计更加安全性的Token。
找回凭证有效性:不论凭证是预留问题,短信还是邮箱都要验证其有效性,以及实用情况。为了保证正确性可以多重验证同时使用。
还有就是操作的时候通过各种人机校验技术(CAPTCHA)对操作的对象进行判断,防止使用程序进行撞库。
其实密码找回这个业务的流程跟要求本身就存在一个安全性与方便性的矛盾。
最安全的做法肯定是让本人持有效证件、证明及办理时的手机来业务办理处进行人工验证。其实这也就是现在很多银行办理密码修改的要求,不过因为太麻烦了,所以一般网站很难做到。所以现在网站一般的密码找回流程都是一个安全性和方便性妥协的产物,求得在风险与方便之间的一个平衡点。这个平衡点的位置是与网站业务的类型有关,比如支付宝的实名验证及密码找回就比一般的网站难得多。
当然在新技术不断发展的时候,也会不断的有新的方便的验证技术出现,找回密码这个业务肯定也会不断的发展,变得更加安全及方便。比如现在的刷脸支付,只要人脸识别及活体检验技术过关,都能直接通过刷脸进行支付及办理业务了,那么又有什么不可以用来找回密码呢?
可以的话,来个帽衫吧。
嗯嗯,很有道理,感觉刷脸和指纹还是比较靠谱的,比验证码找回什么的安全系数要高很多!
刷脸、指纹对技术要求太高。特别是如果还要做3D等活体检测同时有要求很高的成功率,一般企业都难以做到。等哪天阿里把自己的API放出来可能会有戏。
这个其实还和应用的情况有关系,刷脸可是要采集你的相貌的,指纹是要采集你的指纹特征的,可能对于支付宝这样的应用你可以信任一下。一个一般的应用你会同意么?
不同意,被人获取了你的这些生物信息,谁知道在将来会被用于什么地方。如果将来都是人脸识别回家了,那别人在现在保存了你的人脸数据,就能轻松黑进你家了。
是啊,这就是症结了。“信任”这个命题,光靠技术很难彻底解决。