普通网站防暴力破解登录密码的新设计

[laziji]

shield

前端防暴力破解的一个设计

Demo 地址

https://github.com/GitHub-Laziji/shield

描述

传统的防范暴力破解的方法是在前端登录页面增加验证码, 虽然能有一定程度效果, 但是用户也跟着遭罪, 验证码越复杂, 用户登录的失败率越高

于是最近我想了一个新的设计, 前端在登录时采用解密的方式获取密钥, 把密钥与表单以前发往后端, 用密钥来代替验证码

具体细节如下

设计

• 用户在登录页面输完用户名密码, 点击登录
• js 向后端请求密文
• 后端生成一个随机字符串和一个指定范围内的随机数
• 正向拼接 随机字符串 和 随机字符串随机数的加密 得到密文rstr+MD5(rstr+rint)
• 反向拼接 得到 密钥 MD5(rint+rstr)

    randomString = Utils.getUUID();
    randomNumber = Utils.randomInt(range);
    privateText =  randomString + Utils.md5(randomString+randomNumber);
    privateKey = Utils.md5(randomNumber+randomString);

• 将密文传给前端
• 前端通过循环破解随机数

    let randomString = result.substring(0, 32)
    let valueString = result.substring(32)
    let answerString
    for (let i = 0; i < range; i++) {
        let s = crypto.createHash("md5").update(randomString + i).digest('hex')
        if (s == valueString) {
            answerString = crypto.createHash("md5").update(i + randomString).digest('hex')
            break
        }
    }

• 把得到的密钥和表单一起传个后端
• 后端验证密钥的真假

测试

经过测试 10000 次内 md5 加密前端用时不超过 300ms, 用户察觉不到, 但是暴力破解的难道确增加了几千倍, 这意味这本来一个小时能破解的网站, 现在可能要一年才能破解

优势

• 整个流程对后端带来的压力几乎为 0
• 用户无需输入验证码
• 前端延时极小(对人来说)
• 对暴力破解影响极大
• 只需添加部分代码, 无需更改现有的代码
• 条件可控, 随机数的范围完全由后端决定

好多人的关注点都是 "我知道加密方式, 我可以模拟"

这没错 , 这个设计的目的就是让破解的人来模拟这个步骤啊 , 加密方式完全是公开的,

但是你要提交密码就必须 尝试 数千次 的加密 才能获取到密钥 才能提交一次密码

这样是不是就把可尝试密码的频率降到原来的数千分之一了 ?

同一回复

有的人的观点是
"在后端直接延时 1 秒不就好了吗"
"延时令牌之类的"

这些直接通过多线程直接解决了 , 后端对一个回话的延时是没有用的 ,
这个算法限制的是攻击者电脑的算力,

这篇文章主要是探讨这种设计的可行性

以及使用的这种设计所带来安全性的提升

这个算法的优点之一是服务器的运行验证的压力非常小 , 既不需要查询数据库 已不需要复杂的运算

请在同等情况下比较性能

类似这些观点没有价值
"黑客用 N 台肉鸡 请求服务器 照样会蹦 照样可以破解" ---- 如果没有的话可能一台好的计算机就把服务器搞挂了吧
"延时请求, 延时回复之类" --- 攻击者开多线程 , 延时形同虚设 , 无谓的增加服务器的负担

[just1]

模拟你这个流程不就好了

[laziji]

@just1 就是强制黑客来模拟这个流程啊

[cnyang]

同 1l 所说，加解密方法是暴露的，破解的流程只是多增加了一步而已，客户端处理性能够强大，和正常破解时间无差别

[34C]

毫无意义啊…………

[lance6716]

怕不是每次登录都要挖矿…

[bk201]

没看懂,看上去就是增加一次调用时间成本,那直接限定频率不就结束了?

[suley]

有点意思。和比特币的 POW 有点类似，都是强制客户端做一个很耗时的计算，来提高黑客攻击的成本。

不过本来现在暴力破解类型的攻击也很少了，因为稍微靠谱一点的平台都会限制密码错误的次数；

现在主要风险是用户密码泄露，黑客用自动脚本批量尝试登陆泄露的账号密码，基于安全考虑，当用户账号在陌生环境登陆的时候，要求输入验证码，只是为了做图灵测试而已。

[laziji]

@cnyang 你觉得破解时间无差别吗? 普通的电脑暴力破解开多线程 一秒钟可以尝试几千次 , 用了这个 每次都需要出后端传来的密文才能提交密码 一秒钟最多 10 次, 会没有区别吗? 而且加密方法本来就没打算隐藏啊, MD5 不可逆 知道了又如何

[golmic]

毫无意义+1

[adjusted]

有点像 coinhive 的 Proof of Work Captcha

[est]

我跟你们说个新思路：

用户输入错误 3 次密码之后，无论输入什么密码都能进入账户，不过看到的内容全 tm 是假的！

爬虫、脱裤的你们随便抓。能抓到有价值的东西算我输！

[laziji]

@bk201 限制频率 要么使用 cookie 保存 (用程序可以绕过) ,
使用 session 保存 (也可以绕过)
使用数据库限制用户名 (影响普通用户 , 而且需要多张表 , 每次需要差数据库)
使用数据库限制 IP (同上, 而且 ip 可以代理 , 并且同局域网对外是同一个 IP , 比如校园网 一个人违规 所有人都限制了)

[laziji]

@34C 为何?

[VoidChen]

@est 这让我想起了很久以前看到的“蜜罐‘啊

[bk201]

@laziji 你说的都是什么鬼,限制频率很简单,方法很多,搜下就有.你的这种做法其实并不会给暴力破解增加多少难度,因为如果用服务器跑解密比用户浏览器的 js 引擎跑解密快多了,反而你会增加页面代码复杂度以及流畅度.

[qiutianaimeili]

如果单单只是无脑的暴力破解可能比较耗时，可是你这里已经把破解的方法写在前端 js 里了，人家照着你的这个破解方法不就可以破解了吗？

[bk201]

@VoidChen 他这个并不是蜜罐啊.你给我倒是个启发,无论前端发什么过来都登录成功,但是返回的 url 确实一个假 url

[est]

@VoidChen 没错。

[34C]

@laziji

如果是防止通用型的暴力工具，那大部分的通用工具的通用性并不强，所以真的想暴力的，真没几个用通用工具的。

如果写专用工具了，所有代码能直接模拟的流程，都毫无意义，因为看懂你的逻辑了，就那几个函数调用来调用去，有啥意义，浏览器做啥，我工具就跟着做啥。

当年虾米音乐在 flash 播放器里 n 层算法，可以得出 mp3 地址，被我破解之后，写个批量下载工具也就半小时的功夫。

而图形验证码虽然也能破解，但因为涉及图形算法、或者人工打码，无论是效率还是复杂度，都大大提升。

[laziji]

@bk201 看代价的变化啊
原先提交一次请求是不是只需要取出字典中的一个密码 加密 然后提交 ?
现在是不是要 经过 10000 次加密后 解密得到密钥 再提交 用什么工具 电脑性能多好没关系啊
黑客尝试密码的频率是不是降低了一万倍

[34C]

@laziji 你想多了，这点频率的下降，相比网络的耗时，几乎忽略不计，何况还可以多线程同时算

[laziji]

@34C 网络的耗时才是可以多线程大幅下降的
计算力的耗时 多线程没什么效果

[34C]

@laziji 多说无益，你直接上个 demo 让 v 友来试着暴力，无防御的、图形验证码的、你这个算法的，三者一起做对比

[34C]

@laziji 即便没有多一层你的算法，本来就会用多线程，但是网络带宽是有限的啊……

[justfly]

有用处。强制要求登录做一点无用功，正常的单次登录，用户做点无用功没什么影响，但是对于想要靠碰撞得到正确密码的这些无用功累加起来还是挺没效率的。

PS. 如果能把无用功换成某种有意义的东西就更好了，比如挖矿。。。

[bearqq]

让用户挖个矿吧，一个 share 提交一次，多和谐

[laziji]

@34C 对于无防御的后端 暴力破解的上限可能在于 电脑的带宽
但是用了这个明显一台电脑一秒钟能解出的密钥个数极其有限 (并且上限是后端可控制的), 这个时候 网络大部分时候都是空闲的

[l12ab]

Google 的验证码

[laziji]

@bearqq ....这是极端情况 , 可以后端调节 随机数的范围 得到一个合理的计算时间

[xiaket]

@justfly 这个思路好... 用户多了还能挣钱....

[laziji]

@l12ab google 的验证码是这样类似的吗 还不是很了解

[panlilu]

这属于一种 POW ……

[mario85]

图灵测试跟 pow 本质还是不一样的吧

[ZE3kr]

https://coinhive.com/account/login

[DeutschXP]

毫无任何意义
0. 这种计算的成本几乎为零，你说的增加攻破难度，需要一年，只不过是因为无用功造成的时间成本。
1. 用户点击登录后，现在需要两次和后端交互，降低体验度。
2. 与其搞什么计算，不如直接延时发令牌，获取一次性令牌后再延时提交，用户点击登录按钮，显示请等待，后台开始忙活，把平时只需要 100ms 完成的登录验证，变成需要 3 秒才完成。这样一来，按照你的计算方法，本来几小时破解的网站，现在需要几年了呢，比你的一年还厉害。
而且我说的这个方法可以灵活配置。比如希望更长时间，直接延时 30 秒，就变成几十年才能破解了呢。如果登录等待过程改成一部电影的长度，好几辈子都破解不了。

[tiztm]

额，为了延长整个登陆的过程，你直接在后台写个 Thread.sleep(300)不就好了吗。。

[34C]

@DeutschXP 赞同，其实不用这么麻烦，如果楼主坚持增加所谓的算法时间成本，那在验证用户名密码的时候 delay 1s 再响应结果，都提升 100 多倍的耗时了，这个耗时还可以无视攻击者的电脑性能，天河一号来攻击都会需要 1s 才能知道结果

[Ghkitg]

这种有 Key 又有 range 的.全算一次做成彩虹表也花不了多久时间吧

[Ghkitg]

看错了,彩虹表不适用

[fcten]

不错的想法。对暴力破解的防护效果是有的，可以应用在一些安全性要求不高的场合，并且无需收集和记录用户的任何隐私信息。

虽然 JavaScript 的执行速度已经很快了，但是在这种 CPU 密集型的运算中，依然会比 C 慢上一百倍甚至更多。登录的场景不允许让用户等待太久，同时又要考虑到用户设备的硬件差异（例如一些比较老的智能手机）。最终抵御暴力破解的能力会打折扣。

就以楼主的例子来说，普通的台式机上 300ms，放手机上可能需要 3s，而攻击者用一台稍微好一点的机器，只需要 10ms。JavaScript 是单线程的，但是攻击者可以使用所有的 CPU 核心进行并发计算。假如攻击者使用的电脑有 16 个核心，就可以每秒尝试 1600 次。

要知道，合理的风控措施能做做到在支付场景下让用户使用 6 位数字密码。而这种 POW 策略必须搭配一个复杂的密码才能起到效果。

[FanWall]

@DeutschXP #35

“毫无任何意义”是病句

你和 #36 #37 的设计还是会增加服务器的开销，而楼主方案的出发点是“仅”利用客户端的资源而增加暴力破解的成本，并不能说是毫无意义。

[34C]

@FanWall 回你，同回楼主的 append，说得好像楼主这套算法 服务器没增加运算压力一样，论对黑客的电脑和网站的服务器 谁的影响更大，我看还真不一定谁先崩。

[input2output]

https://coinhive.com/documentation/captcha 这个方案不错, 验证还能挖矿

[34C]

跟楼主抬杠了这么多，其实我想表达一个观点，楼主的设计，是出于防御者的角度，所以觉得有用，但如果从攻击者的角度去想，这层防御真的形同虚设，就看有多大攻击价值而已，想要既不影响用户体验又尽可能提升安全的想法是对的，但从多角度考虑作用 也很重要

[fan123199]

应该是种可用的方法，但是我感觉对前端用户应该是有影响的。随机字符串和一个指定范围内的随机数 ，这两个值需要调优。

[34C]

看了楼主最新的 append 简直呵呵哒，你自己的作品开心就好，都说了直接上了 demo 上数据说话

[doubleflower]

这个只是降低了些攻击频率，且也没降太多，毕竟不能让用户久等。
所以做这个还不如在后端加个 IP 重复提交验证呢，一次输错就出验证码。

[FanWall]

@34C #42

例如就算是最简单的对密码加盐哈希，如果说客户端多运算几轮，攻击者就需要进行相同的运算，就需要付出更多成本，而服务端什么付出也没有。

[34C]

@FanWall 关键是楼主的算法 并不是把哈希后的值存数据库直接对比啊，楼主的算法 服务器也是要跟着计算的啊

[swulling]

md5 已经被玩坏了，别说 ASIC，用 GPU 也算的太快。还是用别的没那么快的算法吧

其实最简单按照密码错误次数决定对 IP 封禁一段时间就完了

[chinvo]

安全领域不要自己造轮子，不然就和国内一众银行的 ActiveX 或者网易邮箱的 js md5 一样变成笑料了

对了楼主你这个设计和 网易邮箱的 js md5 是一个逻辑呢……

[zn]

@laziji 楼主，有一点你计算错了，没加这个之前破解速度不会有每秒几千别的，因为这超出了你服务器的处理能力。

[ixx]

总的来说这只是增加了暴力破解的难度 而并没有在根本上解决问题
如果你觉得验证码用户体验不好 47 楼说的 “ IP 重复提交验证，一次输错就出验证码” 是解决办法
如果你是为了防止破解，限制 IP 才是正确的解决方式

[898601566]

@est 用户怎么办?

[cnyang]

@laziji 对，我觉得破解时间就是无差别的☺
正常情况下，服务器并发处理一次密码的时间绝对大于客户端
10000 次 MD5 耗时 300ms 的机器，我不知是什么机器，如果服务器也是这配置，不加密正常的情况下破解成功估计也得百年以上
仅仅是密钥做万次 md5 的话，我相信这个时间还是低于服务器查询数据库并发送给客户端的时间，所以攻击端有一台不低于服务器配置的机器就行了（实际情况攻击端配置不说百倍，两三倍总有吧）

[est]

@898601566 一般用户不会输错密码 3 次以上。

[cnyang]

@laziji 另外再补充一点，你说的“每次都需要出后端传来的密文才能提交密码，一秒钟最多 10 次"，话说我为啥要等待后端处理完成后再提交，有个词叫“并发”
上面回复那条中的时间再加一个后端二次处理密文并发送的时间

[cnyang]

所以说，你的这个想法得加上一个限制每秒提交次数或密码错误几次就 block 的条件，既然都能这样，何必加密呢，正常情况破解对于攻击端也是无解的

[DeutschXP]

@FanWall 我说的方案不比楼主的更消耗服务器资源，却比楼主方案更节约了客户端资源。
楼主的方案说白了就是：服务器给道题，客户端算出来答案，传给服务器端验证答案。这个过程唯一的意义就是拖延时间，没有其他任何实际价值，比如验证真人。
而我的方案是：服务器给令牌，带时间戳，客户端传回时间戳，服务器比对，时间戳如果间隔小于设定值，直接忽略。
把我的方案再简化一下，就是现在好多网站已经在做的了，登录表单带 token 和时间戳。用户提交时直接比对，时间间隔太小可以视为是机器攻击，结束。
同样是客户端等待，又不是服务器 sleep 再输出，从何而来增加服务器消耗？

[x86]

错误 xx 次以后，错 1 次 ban 1 次 ip 如何

[gam2046]

想法很不错呀，不知道上面的各位槽点在哪里呢？

不过我觉得错 N 次，阻止继续登陆 X 小时，就足够了。

你的方案是建立在允许无限重试的情况下，但是实际中，很少有允许无穷测试的情况存在呀。

[kenorizon]

本质上和服务器上延迟 1000ms 才响应是一样的，多线程可破，还增加了服务器的压力。
如果说这种方案在服务器的运行验证的压力非常小，那么这种方案形成的障碍对攻击者而言也一样微不足道了。

[LucasLee92]

@gam2046 想法是不错，但是现在网站密码的痛点应该是在 @suley 所提出的问题

[hicdn]

@est 会超过 3 次，长时间不登录的网站，密码要多试几次才能对上。以前用一些规则来生成密码，中间升级过算法，经常忘了网站用的哪套算法生成的密码，只好遍历了。用了密码管理工具后就没这问题了。

[xmbaozi]

虽然应用场景不多，起码是一个独特的思路。

[hahastudio]

@hicdn 这样你应该用重置密码的功能

[dallaslu]

知乎上有提问，不过回答的不多
https://www.zhihu.com/question/47373358

使用类似原理的验证服务
https://coinhive.com/documentation/captcha

相关研究
https://eprint.iacr.org/2016/145.pdf

[zhangyuting]

你的想法是合理的，我听起来像是 hashcash 的原理，你觉得呢？

[suley]

@x86 你说的就是现在通用的做法，不新鲜，ban ip, ban 账号, ban 设备指纹, ban cookie, ban mac...很多网站 /app 都有这样的规则了。

[honeycomb]

可以考虑让前端跑一个 scrypt/bcrypt/argon，而不是 md5

[snw]

首先你要考虑访客客户端性能可能多差，以及不同浏览器的执行效率。你电脑上特定跑 300ms，访客破手机上另一个浏览器可能卡死几秒甚至十几秒。
其次 md5 高速运算很容易，攻击者有心的话不一定用浏览器去跑，而是用高效语言重写一下，参数扔进去借助 GPU 去算，算完后回传浏览器，可能平均只需几毫秒。这也就意味着攻击者可以模仿上千个正常访客。

顺便吐槽下工商企业信息公示系统用的宇创防护，好像也用了些奇技淫巧，经常导致浏览器卡死。

[imn1]

只看到「前端」两个字，就看完了

[lain0]

防暴破的 hash 算法 scrypt/bcrypt 的基本思路也是如此，樓主這個把工作量證明的計算放到前端的想法很聰明。樓主是否學過加密學的課程？

不過驗證碼的作用除了防止暴力破解之外還可以防止機器人登入。

[Mohanson]

楼上有个兄台说的好, 为什么不直接服务器延迟响应 300 ms.

[laziji]

@zhangyuting 这个设计只是偶然的突发奇想 , 觉得这个可行 . 你说的 hashcash 我刚刚去查了一下资料 异曲同工啊 , 在邮件过滤方面有应用, 不错啊 有机会可以探讨一下

[wobushizhangsan]

把随机数范围也从后端返回，错的越多返回随机数越大。不过仅有前端也不行，后端还得要 ip 拉黑，用户名拉黑功能。

[zzNucker]

这想法就是个 POW 啊，又不新鲜。。。。。 楼上还这么多人抨击 。。。

[laziji]

@lain0 有粗略了解过加密学 , 你说的验证码防机器人我也非常赞同 , 不过现在好多网站的验证码通过图像识别很好识别出来, 所以尝试从其他方向解决这个问题 就想到了这个设计 , 还要很多不足的地方 待改进.

[wobushizhangsan]

把随机数范围也从后端返回，错的越多返回随机数越大。不过仅有前端挖矿也不行，后端还得有 ip 拉黑，用户名拉黑功能。

[laziji]

@wobushizhangsan 谢谢你的建议 , 其实随机数范围可返回也可以不返回 因为前端从 0 开始遍历 总会找到那个答案 , 不过这个对全心就是想破解你这个网站的攻击者来说 确实不够安全 , IP , 用户名 加上其他的机制也是必须的 , 这个设计最大的意义是把大部分攻击者拦在第一道门前, 减少服务器压力

[geelaw]

这个想法不新奇。但我觉得服务端限制一个用户延迟 1s 且同时只能有一个客户端尝试登录，再加上出错加时间限制更现实一些。用 proof of power 来放缓攻击速度是一个很漂亮的应用（包括有一种反垃圾邮件的技术也用了类似的想法），但通常来说“因没有什么实用价值而只配放进博物馆供人观赏”。

@laziji #80 按顺序计算是很诡异的，你应该用生日攻击——算出来答案需要的期望时间不超过 sqrt range。

但是问题在于 JS 的运行速度和实际的攻击者的速度是完全不同的。

[ex2vkf]

程序员何苦难为程序员

[laziji]

@geelaw "放缓攻击"我觉得形容的非常准确, 单单只用这种防御 必然是不安全的, 但是这个的好处就是可以附加在任何现有的防御上, 减慢攻击者攻击第二道屏障的速度 , 第二道屏障如果是 ip 限制之类的 就意味着可能要查询数据库 代价更大一些, 所以我觉得还是有一定意义的.

[shiny]

@est 不常用的网站完全有可能输错三次以上密码

[oovveeaarr]

LZ 忽略了一个问题，纯 CPU 计算从来不是瓶颈，瓶颈是 IO 传输。打个比方，就拿暴力登录来说，费时的是去数据库查询，而不是对比数据的这个过程。
最简单的，把账号密码在 PHP 里面写死，和在数据库里面查，速度就不是一个等级。而 LZ 这个假设是基于，目前自己的系统已经跟得上黑客破解的级别了（比如说一秒钟几万次登录请求之类的）。然而实际上，在网络情况下这根本达不到，最多几百 req/s。
在这种情况下，LZ 这种降低用户体验的方法，对于黑扩来说完全没有压力呀，因为如果是纯 CPU 操作，那么还是能达到几百 /req/s 这个级别，别人根本就不走你的正常浏览器 JavaScript 流程，没准别人调用个 C 语言、Java 就快很多，甚至可以上 GPU，一下子就跑好了。但是你设置的 cost （成本）太高了，势必对一些用户造成很差的体验，还会认为你在挖矿。
所以我还是站在没什么用这个角度的。

[oovveeaarr]

对了，如果要控制速度的话，完全没有必要这么麻烦，提交密文密码就好了。
用 bcrypt 可以控制 cost （加密成本），非常适合来做“放缓攻击”。

[laziji]

@oovveeaarr 嗯 感谢回复, 确实是基于服务器性能不错的情况之上 , 在没有实际应用之前 说不准效果会如何 , 有机会我会在网站上部署这种防御机制 看看效果如何

[laziji]

@oovveeaarr 这种方式有了解, 对比我这种交互式设计, 我的优势是 速率后端可控 , 以及可以附加在现有系统之上. 不需要改动原来的 项目结构

[pynix]

你这是在用浏览器挖矿吧。。。

[shiny]

参考这个帖子： /t/339941

[leoleoasd]

任何服务器端延迟判断 /通过判断时间来强制客户端延迟提交的方式都可以通过多线程来解决,不需要算力
只是增加了验证所需要的延迟 但是单位时间内验证的密码数量是相同的.

[oovveeaarr]

@laziji #88 其实吧，说句实话，我觉得在一定程度上这已经是个伪命题了。因为其实每秒“几百次，几千次”的尝试，已经不算通常意义上的“暴力破解了”，一个彩虹表（常用密码以及常用密码的变种和组合）都能有几 T，几十 T。几百次和几千次的差距也就 100 倍内，对于整个基数来说并不是很重要。
说句不太好听的，其实 LZ 一开始就搞错了验证码的作用。验证码主要做的是人机测试，也就是所谓的“ I am not robot/我不是机器人”（跟图灵测试还是不一样的）。他的主要目的是辨别操作者是否人类，这是从根本上解决的，而不是防止用户输密码的速度太快之类的（表象）。
再说了，无限尝试的地方也很少见呀，一般频率限制已经足够了，比如说根据账号来限制频率，比如说这个账号我 5 秒就给他进行一次测试，你多了的我就忽略（跟 QQ 的发言频率限制一样）。

说句题外话，目前广泛的“验证码”，不管是随机字符，还是利用什么大数据，深度学习，什么行为分析的，拖动式的，甚至 Google recaptcha，主要就是在两方面下功夫。
1 ）难度控制
2 ）行为分析
行为分析主要就是通过其他数据，来鉴别你到底是不是人的模型，然和再综合这个打分和你之前的错误尝试来算出难度。
最直观的例子就是 QQ 的验证码，之前忘记在哪里看到腾讯的分享了，主要就是在说，QQ 会一次给出很多种模式的验证码，看看你输对最多的是哪种（几十次尝试中），然和就删掉那种简单的，出你识别不出来的这个样子。这就是最简单的所谓“基于行为分析”的验证码。
至于 Google 就更复杂了一些，利用了计算机对于视觉还有音讯资料无法直接识别的问题，还有一些其他东西，应该都有论文或者可以百度到。

[mejee]

我一般是密码错误就返回”当前登陆 IP 不在白名单” 😄

[mejee]

楼主你这个没啥大意义，攻击者直接执行你得前端代码就 ok 了，只能过滤掉低级攻击者

[mytsing520]

被破解的概率下降，但是这和你描述的场景根本不同。验证码或频率限制用于验证是否真人登录。
简单点，为了避免被破解，我们使用了账户登录频率限制功能，一旦有人试错密码，试错三次则账号直接锁死。用户持有人需要凭电话或在线验证方式解封账户，解封后系统会自动重置新密码并以短信方式发送到用户手机上。
更复杂点，我还可以设计在此基础上过去使用过的密码排除验证，即已经使用过的密码，未来 N 次内都不能再使用。

[est]

@hicdn 巧了，我会用心搜集你输错的密码。说不定有用。哈哈哈

[jq8778]

干脆做成让客户端挖矿，用户名和密码+SALT 后 SHA256，结果包含在区块头结构里，按指定区块头算出指定难度以上才提交
第一次难度设置 1，后续同一账户，每错一个，难度翻倍
24 小时重置
然后首页打出广告：欢迎各大黑客暴力破解，本站登陆不设验证码，对，就是那么自信 XD

[dndx]

这都是人家 90 年代玩剩下的技术：

https://en.wikipedia.org/wiki/Hashcash

[yangqi]

楼主最基本的尝试都没有搞清楚啊，你没法判断你的前端是正常用户还是机器，目前唯一的办法就是各种验证码。你搞再多的算法幺蛾子没用的。

“经过测试 10000 次内 md5 加密前端用时不超过 300ms, 用户察觉不到, 但是暴力破解的难道确增加了几千倍, 这意味这本来一个小时能破解的网站, 现在可能要一年才能破解”

现在的暴力破解是不停的提交登录请求来试出正确密码，瓶颈根本就不在计算能力，而是网络响应。你 10000 次 300ms, 破解的只需要照搬你的函数一样的，难度并没有增加，最多就是比之前慢了一点，和楼上说的服务器加延时并没有区别。

[tangzhangming]

简单的说，你压根没明白这个功能的痛点在哪儿