
https://github.com/GitHub-Laziji/shield
传统的防范暴力破解的方法是在前端登录页面增加验证码, 虽然能有一定程度效果, 但是用户也跟着遭罪, 验证码越复杂, 用户登录的失败率越高
于是最近我想了一个新的设计, 前端在登录时采用解密的方式获取密钥, 把密钥与表单以前发往后端, 用密钥来代替验证码
具体细节如下
随机字符串和一个指定范围内的随机数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, 用户察觉不到, 但是暴力破解的难道确增加了几千倍, 这意味这本来一个小时能破解的网站, 现在可能要一年才能破解
1 just1 2018-07-17 13:00:16 +08:00 via Android 模拟你这个流程不就好了 |
3 bigtwo 2018-07-17 13:16:42 +08:00 同 1l 所说,加解密方法是暴露的,破解的流程只是多增加了一步而已,客户端处理性能够强大,和正常破解时间无差别 |
4 34C 2018-07-17 13:21:21 +08:00 via iPhone 毫无意义啊………… |
5 lance6716 2018-07-17 13:26:53 +08:00 via Android 怕不是每次登录都要挖矿… |
6 bk201 2018-07-17 13:27:05 +08:00 没看懂,看上去就是增加一次调用时间成本,那直接限定频率不就结束了? |
7 suley 2018-07-17 13:28:10 +08:00 有点意思。和比特币的 POW 有点类似,都是强制客户端做一个很耗时的计算,来提高黑客攻击的成本。 不过本来现在暴力破解类型的攻击也很少了,因为稍微靠谱一点的平台都会限制密码错误的次数; 现在主要风险是用户密码泄露,黑客用自动脚本批量尝试登陆泄露的账号密码,基于安全考虑,当用户账号在陌生环境登陆的时候,要求输入验证码,只是为了做图灵测试而已。 |
8 laziji OP @cnyang 你觉得破解时间无差别吗? 普通的电脑暴力破解开多线程 一秒钟可以尝试几千次 , 用了这个 每次都需要出后端传来的密文才能提交密码 一秒钟最多 10 次, 会没有区别吗? 而且加密方法本来就没打算隐藏啊, MD5 不可逆 知道了又如何 |
9 golmic 2018-07-17 13:30:00 +08:00 毫无意义+1 |
10 adjusted 2018-07-17 13:31:48 +08:00 有点像 coinhive 的 Proof of Work Captcha |
11 est 2018-07-17 13:32:04 +08:00 我跟你们说个新思路: 用户输入错误 3 次密码之后,无论输入什么密码都能进入账户,不过看到的内容全 tm 是假的! 爬虫、脱裤的你们随便抓。能抓到有价值的东西算我输! |
12 laziji OP @bk201 限制频率 要么使用 cookie 保存 (用程序可以绕过) , 使用 session 保存 (也可以绕过) 使用数据库限制用户名 (影响普通用户 , 而且需要多张表 , 每次需要差数据库) 使用数据库限制 IP (同上, 而且 ip 可以代理 , 并且同局域网对外是同一个 IP , 比如校园网 一个人违规 所有人都限制了) |
15 bk201 2018-07-17 13:39:43 +08:00 @laziji 你说的都是什么鬼,限制频率很简单,方法很多,搜下就有.你的这种做法其实并不会给暴力破解增加多少难度,因为如果用服务器跑解密比用户浏览器的 js 引擎跑解密快多了,反而你会增加页面代码复杂度以及流畅度. |
16 qiutianaimeili 2018-07-17 13:40:52 +08:00 如果单单只是无脑的暴力破解可能比较耗时,可是你这里已经把破解的方法写在前端 js 里了,人家照着你的这个破解方法不就可以破解了吗? |
19 34C 2018-07-17 13:44:56 +08:00 via iPhone @laziji 如果是防止通用型的暴力工具,那大部分的通用工具的通用性并不强,所以真的想暴力的,真没几个用通用工具的。 如果写专用工具了,所有代码能直接模拟的流程,都毫无意义,因为看懂你的逻辑了,就那几个函数调用来调用去,有啥意义,浏览器做啥,我工具就跟着做啥。 当年虾米音乐在 flash 播放器里 n 层算法,可以得出 mp3 地址,被我破解之后,写个批量下载工具也就半小时的功夫。 而图形验证码虽然也能破解,但因为涉及图形算法、或者人工打码,无论是效率还是复杂度,都大大提升。 |
20 laziji OP @bk201 看代价的变化啊 原先提交一次请求是不是只需要取出字典中的一个密码 加密 然后提交 ? 现在是不是要 经过 10000 次加密后 解密得到密钥 再提交 用什么工具 电脑性能多好没关系啊 黑客尝试密码的频率是不是降低了一万倍 |
23 34C 2018-07-17 13:57:22 +08:00 via iPhone @laziji 多说无益,你直接上个 demo 让 v 友来试着暴力,无防御的、图形验证码的、你这个算法的,三者一起做对比 |
25 justfly 2018-07-17 14:00:46 +08:00 有用处。强制要求登录做一点无用功,正常的单次登录,用户做点无用功没什么影响,但是对于想要靠碰撞得到正确密码的这些无用功累加起来还是挺没效率的。 PS. 如果能把无用功换成某种有意义的东西就更好了,比如挖矿。。。 |
26 bearqq 2018-07-17 14:07:56 +08:00 via Android 让用户挖个矿吧,一个 share 提交一次,多和谐 |
27 laziji OP @34C 对于无防御的后端 暴力破解的上限可能在于 电脑的带宽 但是用了这个明显一台电脑一秒钟能解出的密钥个数极其有限 (并且上限是后端可控制的), 这个时候 网络大部分时候都是空闲的 |
28 l12ab 2018-07-17 14:08:38 +08:00 via iPhone Google 的验证码 |
32 panlilu 2018-07-17 14:13:44 +08:00 这属于一种 POW …… |
33 mario85 2018-07-17 14:13:45 +08:00 via iPhone 图灵测试跟 pow 本质还是不一样的吧 |
34 ZE3kr 2018-07-17 14:15:00 +08:00 via iPhone |
35 DeutschXP 2018-07-17 14:18:58 +08:00 via iPhone 毫无任何意义 0. 这种计算的成本几乎为零,你说的增加攻破难度,需要一年,只不过是因为无用功造成的时间成本。 1. 用户点击登录后,现在需要两次和后端交互,降低体验度。 2. 与其搞什么计算,不如直接延时发令牌,获取一次性令牌后再延时提交,用户点击登录按钮,显示请等待,后台开始忙活,把平时只需要 100ms 完成的登录验证,变成需要 3 秒才完成。这样一来,按照你的计算方法,本来几小时破解的网站,现在需要几年了呢,比你的一年还厉害。 而且我说的这个方法可以灵活配置。比如希望更长时间,直接延时 30 秒,就变成几十年才能破解了呢。如果登录等待过程改成一部电影的长度,好几辈子都破解不了。 |
36 tiztm 2018-07-17 14:22:49 +08:00 额,为了延长整个登陆的过程,你直接在后台写个 Thread.sleep(300)不就好了吗。。 |
37 34C 2018-07-17 14:25:43 +08:00 via iPhone @DeutschXP 赞同,其实不用这么麻烦,如果楼主坚持增加所谓的算法时间成本,那在验证用户名密码的时候 delay 1s 再响应结果,都提升 100 多倍的耗时了,这个耗时还可以无视攻击者的电脑性能,天河一号来攻击都会需要 1s 才能知道结果 |
38 Ghkitg 2018-07-17 14:26:42 +08:00 这种有 Key 又有 range 的.全算一次做成彩虹表也花不了多久时间吧 |
39 Ghkitg 2018-07-17 14:29:02 +08:00 看错了,彩虹表不适用 |
40 fcten 2018-07-17 14:31:40 +08:00 不错的想法。对暴力破解的防护效果是有的,可以应用在一些安全性要求不高的场合,并且无需收集和记录用户的任何隐私信息。 虽然 Javascript 的执行速度已经很快了,但是在这种 CPU 密集型的运算中,依然会比 C 慢上一百倍甚至更多。登录的场景不允许让用户等待太久,同时又要考虑到用户设备的硬件差异(例如一些比较老的智能手机)。最终抵御暴力破解的能力会打折扣。 就以楼主的例子来说,普通的台式机上 300ms,放手机上可能需要 3s,而攻击者用一台稍微好一点的机器,只需要 10ms。Javascript 是单线程的,但是攻击者可以使用所有的 CPU 核心进行并发计算。假如攻击者使用的电脑有 16 个核心,就可以每秒尝试 1600 次。 要知道,合理的风控措施能做做到在支付场景下让用户使用 6 位数字密码。而这种 POW 策略必须搭配一个复杂的密码才能起到效果。 |
41 FanWall 2018-07-17 14:36:15 +08:00 via Android |
42 34C 2018-07-17 14:40:00 +08:00 via iPhone @FanWall 回你,同回楼主的 append,说得好像楼主这套算法 服务器没增加运算压力一样,论对黑客的电脑和网站的服务器 谁的影响更大,我看还真不一定谁先崩。 |
43 input2output 2018-07-17 14:41:55 +08:00 https://coinhive.com/documentation/captcha 这个方案不错, 验证还能挖矿 |
44 34C 2018-07-17 14:46:34 +08:00 via iPhone 跟楼主抬杠了这么多,其实我想表达一个观点,楼主的设计,是出于防御者的角度,所以觉得有用,但如果从攻击者的角度去想,这层防御真的形同虚设,就看有多大攻击价值而已,想要既不影响用户体验又尽可能提升安全的想法是对的,但从多角度考虑作用 也很重要 |
45 fan123199 2018-07-17 14:50:18 +08:00 应该是种可用的方法,但是我感觉对前端用户应该是有影响的。随机字符串和一个指定范围内的随机数 ,这两个值需要调优。 |
46 34C 2018-07-17 14:58:17 +08:00 via iPhone 看了楼主最新的 append 简直呵呵哒,你自己的作品开心就好,都说了直接上了 demo 上数据说话 |
47 doubleflower 2018-07-17 14:58:23 +08:00 这个只是降低了些攻击频率,且也没降太多,毕竟不能让用户久等。 所以做这个还不如在后端加个 IP 重复提交验证呢,一次输错就出验证码。 |
48 FanWall 2018-07-17 14:59:38 +08:00 via Android |
49 34C 2018-07-17 15:02:15 +08:00 via iPhone @FanWall 关键是楼主的算法 并不是把哈希后的值存数据库直接对比啊,楼主的算法 服务器也是要跟着计算的啊 |
50 swulling 2018-07-17 15:04:41 +08:00 md5 已经被玩坏了,别说 ASIC,用 GPU 也算的太快。还是用别的没那么快的算法吧 其实最简单按照密码错误次数决定对 IP 封禁一段时间就完了 |
51 chinvo 2018-07-17 15:07:26 +08:00 via iPhone 安全领域不要自己造轮子,不然就和国内一众银行的 ActiveX 或者网易邮箱的 js md5 一样变成笑料了 对了楼主你这个设计和 网易邮箱的 js md5 是一个逻辑呢…… |
52 zn 2018-07-17 15:09:48 +08:00 via iPhone @laziji 楼主,有一点你计算错了,没加这个之前破解速度不会有每秒几千别的,因为这超出了你服务器的处理能力。 |
53 ixx 2018-07-17 15:10:30 +08:00 总的来说这只是增加了暴力破解的难度 而并没有在根本上解决问题 如果你觉得验证码用户体验不好 47 楼说的 “ IP 重复提交验证,一次输错就出验证码” 是解决办法 如果你是为了防止破解,限制 IP 才是正确的解决方式 |
54 < href="/member/898601566" class="dark">898601566 2018-07-17 15:13:25 +08:00 @est 用户怎么办? |
55 bigtwo 2018-07-17 15:18:07 +08:00 @laziji 对,我觉得破解时间就是无差别的 正常情况下,服务器并发处理一次密码的时间绝对大于客户端 10000 次 MD5 耗时 300ms 的机器,我不知是什么机器,如果服务器也是这配置,不加密正常的情况下破解成功估计也得百年以上 仅仅是密钥做万次 md5 的话,我相信这个时间还是低于服务器查询数据库并发送给客户端的时间,所以攻击端有一台不低于服务器配置的机器就行了(实际情况攻击端配置不说百倍,两三倍总有吧) |
57 bigtwo 2018-07-17 15:23:13 +08:00 @laziji 另外再补充一点,你说的“每次都需要出后端传来的密文才能提交密码,一秒钟最多 10 次",话说我为啥要等待后端处理完成后再提交,有个词叫“并发” 上面回复那条中的时间再加一个后端二次处理密文并发送的时间 |
58 bigtwo 2018-07-17 15:26:13 +08:00 所以说,你的这个想法得加上一个限制每秒提交次数或密码错误几次就 block 的条件,既然都能这样,何必加密呢,正常情况破解对于攻击端也是无解的 |
59 DeutschXP 2018-07-17 16:39:20 +08:00 via iPhone @FanWall 我说的方案不比楼主的更消耗服务器资源,却比楼主方案更节约了客户端资源。 楼主的方案说白了就是:服务器给道题,客户端算出来答案,传给服务器端验证答案。这个过程唯一的意义就是拖延时间,没有其他任何实际价值,比如验证真人。 而我的方案是:服务器给令牌,带时间戳,客户端传回时间戳,服务器比对,时间戳如果间隔小于设定值,直接忽略。 把我的方案再简化一下,就是现在好多网站已经在做的了,登录表单带 token 和时间戳。用户提交时直接比对,时间间隔太小可以视为是机器攻击,结束。 同样是客户端等待,又不是服务器 sleep 再输出,从何而来增加服务器消耗? |
60 x86 2018-07-17 16:41:51 +08:00 错误 xx 次以后,错 1 次 ban 1 次 ip 如何 |
61 gam2046 2018-07-17 16:47:19 +08:00 想法很不错呀,不知道上面的各位槽点在哪里呢? 不过我觉得错 N 次,阻止继续登陆 X 小时,就足够了。 你的方案是建立在允许无限重试的情况下,但是实际中,很少有允许无穷测试的情况存在呀。 |
62 kenorizon 2018-07-17 16:56:57 +08:00 本质上和服务器上延迟 1000ms 才响应是一样的,多线程可破,还增加了服务器的压力。 如果说这种方案在服务器的运行验证的压力非常小,那么这种方案形成的障碍对攻击者而言也一样微不足道了。 |
63 LucasLee92 2018-07-17 16:57:50 +08:00 |
64 hicdn 2018-07-17 16:58:30 +08:00 @est 会超过 3 次,长时间不登录的网站,密码要多试几次才能对上。以前用一些规则来生成密码,中间升级过算法,经常忘了网站用的哪套算法生成的密码,只好遍历了。用了密码管理工具后就没这问题了。 |
65 xmbaozi 2018-07-17 16:58:47 +08:00 虽然应用场景不多,起码是一个独特的思路。 |
66 hahastudio 2018-07-17 17:02:16 +08:00 @hicdn 这样你应该用重置密码的功能 |
67 dallaslu 2018-07-17 17:03:07 +08:00 |
68 zhangyuting 2018-07-17 17:05:07 +08:00 你的想法是合理的,我听起来像是 hashcash 的原理,你觉得呢? |
69 suley 2018-07-17 17:41:43 +08:00 @x86 你说的就是现在通用的做法,不新鲜,ban ip, ban 账号, ban 设备指纹, ban cookie, ban mac...很多网站 /app 都有这样的规则了。 |
70 honeycomb 2018-07-17 18:03:32 +08:00 via Android 可以考虑让前端跑一个 scrypt/bcrypt/argon,而不是 md5 |
71 snw 2018-07-17 18:04:29 +08:00 首先你要考虑访客客户端性能可能多差,以及不同浏览器的执行效率。你电脑上特定跑 300ms,访客破手机上另一个浏览器可能卡死几秒甚至十几秒。 其次 md5 高速运算很容易,攻击者有心的话不一定用浏览器去跑,而是用高效语言重写一下,参数扔进去借助 GPU 去算,算完后回传浏览器,可能平均只需几毫秒。这也就意味着攻击者可以模仿上千个正常访客。 顺便吐槽下工商企业信息公示系统用的宇创防护,好像也用了些奇技淫巧,经常导致浏览器卡死。 |
72 imn1 2018-07-17 18:44:49 +08:00 只看到「前端」两个字,就看完了 |
73 lain0 2018-07-17 18:49:29 +08:00 防暴破的 hash 算法 scrypt/bcrypt 的基本思路也是如此,主把工作量明的算放到前端的想法很明。主是否加密的程? 不的作用除了防止暴力破解之外可以防止器人登入。 |
74 Mohanson 2018-07-17 19:03:53 +08:00 楼上有个兄台说的好, 为什么不直接服务器延迟响应 300 ms. |
75 laziji OP @zhangyuting 这个设计只是偶然的突发奇想 , 觉得这个可行 . 说的 hashcash 我刚刚去查了一下资料 异曲同工啊 , 在邮件过滤方面有应用, 不错啊 有机会可以探讨一下 |
76 wobushizhangsan 2018-07-17 19:28:23 +08:00 via Android 把随机数范围也从后端返回,错的越多返回随机数越大。不过仅有前端也不行,后端还得要 ip 拉黑,用户名拉黑功能。 |
77 zzNucker 2018-07-17 19:29:12 +08:00 这想法就是个 POW 啊,又不新鲜。。。。。 楼上还这么多人抨击 。。。 |
78 laziji OP @lain0 有粗略了解过加密学 , 你说的验证码防机器人我也非常赞同 , 不过现在好多网站的验证码通过图像识别很好识别出来, 所以尝试从其他方向解决这个问题 就想到了这个设计 , 还要很多不足的地方 待改进. |
79 wobushizhangsan 2018-07-17 19:32:31 +08:00 via Android 把随机数范围也从后端返回,错的越多返回随机数越大。不过仅有前端挖矿也不行,后端还得有 ip 拉黑,用户名拉黑功能。 |
80 laziji OP @wobushizhangsan 谢谢你的建议 , 其实随机数范围可返回也可以不返回 因为前端从 0 开始遍历 总会找到那个答案 , 不过这个对全心就是想破解你这个网站的攻击者来说 确实不够安全 , IP , 用户名 加上其他的机制也是必须的 , 这个设计最大的意义是把大部分攻击者拦在第一道门前, 减少服务器压力 |
81 geelaw 2018-07-17 19:53:33 +08:00 via iPhone 这个想法不新奇。但我觉得服务端限制一个用户延迟 1s 且同时只能有一个客户端尝试登录,再加上出错加时间限制更现实一些。用 proof of power 来放缓攻击速度是一个很漂亮的应用(包括有一种反垃圾邮件的技术也用了类似的想法),但通常来说“因没有什么实用价值而只配放进博物馆供人观赏”。 @laziji #80 按顺序计算是很诡异的,你应该用生日攻击算出来答案需要的期望时间不超过 sqrt range。 但是问题在于 JS 的运行速度和实际的攻击者的速度是完全不同的。 |
82 ex2vkf 2018-07-17 20:07:54 +08:00 via iPhone 程序员何苦难为程序员 |
83 laziji OP @geelaw "放缓攻击"我觉得形容的非常准确, 单单只用这种防御 必然是不安全的, 但是这个的好处就是可以附加在任何现有的防御上, 减慢攻击者攻击第二道屏障的速度 , 第二道屏障如果是 ip 限制之类的 就意味着可能要查询数据库 代价更大一些, 所以我觉得还是有一定意义的. |
85 oovveeaarr 2018-07-17 20:16:08 +08:00 LZ 忽略了一个问题,纯 CPU 计算从来不是瓶颈,瓶颈是 IO 传输。打个比方,就拿暴力登录来说,费时的是去数据库查询,而不是对比数据的这个过程。 最简单的,把账号密码在 PHP 里面写死,和在数据库里面查,速度就不是一个等级。而 LZ 这个假设是基于,目前自己的系统已经跟得上黑客破解的级别了(比如说一秒钟几万次登录请求之类的)。然而实际上,在网络情况下这根本达不到,最多几百 req/s。 在这种情况下,LZ 这种降低用户体验的方法,对于黑扩来说完全没有压力呀,因为如果是纯 CPU 操作,那么还是能达到几百 /req/s 这个级别,别人根本就不走你的正常浏览器 Javascript 流程,没准别人调用个 C 语言、Java 就快很多,甚至可以上 GPU,一下子就跑好了。但是你设置的 cost (成本)太高了,势必对一些用户造成很差的体验,还会认为你在挖矿。 所以我还是站在没什么用这个角度的。 |
86 oovveeaarr 2018-07-17 20:19:09 +08:00 对了,如果要控制速度的话,完全没有必要这么麻烦,提交密文密码就好了。 用 bcrypt 可以控制 cost (加密成本),非常适合来做“放缓攻击”。 |
87 laziji OP @oovveeaarr 嗯 感谢回复, 确实是基于服务器性能不错的情况之上 , 在没有实际应用之前 说不准效果会如何 , 有机会我会在网站上部署这种防御机制 看看效果如何 |
88 laziji OP @oovveeaarr 这种方式有了解, 对比我这种交互式设计, 我的优势是 速率后端可控 , 以及可以附加在现有系统之上. 不需要改动原来的 项目结构 |
89 pynix 2018-07-17 20:31:17 +08:00 你这是在用浏览器挖矿吧。。。 |
91 leoleoasd 2018-07-17 20:43:23 +08:00 任何服务器端延迟判断 /通过判断时间来强制客户端延迟提交的方式都可以通过多线程来解决,不需要算力 只是增加了验证所需要的延迟 但是单位时间内验证的密码数量是相同的. |
92 oovveeaarr 2018-07-17 20:43:32 +08:00 @laziji #88 其实吧,说句实话,我觉得在一定程度上这已经是个伪命题了。因为其实每秒“几百次,几千次”的尝试,已经不算通常意义上的“暴力破解了”,一个彩虹表(常用密码以及常用密码的变种和组合)都能有几 T,几十 T。几百次和几千次的差距也就 100 倍内,对于整个基数来说并不是很重要。 说句不太好听的,其实 LZ 一开始就搞错了验证码的作用。验证码主要做的是人机测试,也就是所谓的“ I am not robot/我不是机器人”(跟图灵测试还是不一样的)。他的主要目的是辨别操作者是否人类,这是从根本上解决的,而不是防止用户输密码的速度太快之类的(表象)。 再说了,无限尝试的地方也很少见呀,一般频率限制已经足够了,比如说根据账号来限制频率,比如说这个账号我 5 秒就给他进行一次测试,你多了的我就忽略(跟 QQ 的发言频率限制一样)。 说句题外话,目前广泛的“验证码”,不管是随机字符,还是利用什么大数据,深度学习,什么行为分析的,拖动式的,甚至 Google recaptcha,主要就是在两方面下功夫。 1 )难度控制 2 )行为分析 行为分析主要就是通过其他数据,来鉴别你到底是不是人的模型,然和再综合这个打分和你之前的错误尝试来算出难度。 最直观的例子就是 QQ 的验证码,之前忘记在哪里看到腾讯的分享了,主要就是在说,QQ 会一次给出很多种模式的验证码,看看你输对最多的是哪种(几十次尝试中),然和就删掉那种简单的,出你识别不出来的这个样子。这就是最简单的所谓“基于行为分析”的验证码。 至于 Google 就更复杂了一些,利用了计算机对于视觉还有音讯资料无法直接识别的问题,还有一些其他东西,应该都有论文或者可以百度到。 |
93 temp178 2018-07-17 20:46:48 +08:00 via Android 我一般是密码错误就返回”当前登陆 IP 不在白名单” |
94 temp178 2018-07-17 20:51:57 +08:00 via Android 楼主你这个没啥大意义,攻击者直接执行你得前端代码就 ok 了,只能过滤掉低级攻击者 |
95 mytsing520 PRO 被破解的概率下降,但是这和你描述的场景根本不同。验证码或频率限制用于验证是否真人登录。 简单点,为了避免被破解,我们使用了账户登录频率限制功能,一旦有人试错密码,试错三次则账号直接锁死。用户持有人需要凭电话或在线验证方式解封账户,解封后系统会自动重置新密码并以短信方式发送到用户手机上。 更复杂点,我还可以设计在此基础上过去使用过的密码排除验证,即已经使用过的密码,未来 N 次内都不能再使用。 |
97 jq8778 2018-07-18 01:21:20 +08:00 干脆做成让客户端挖矿,用户名和密码+SALT 后 SHA256,结果包含在区块头结构里,按指定区块头算出指定难度以上才提交 第一次难度设置 1,后续同一账户,每错一个,难度翻倍 24 小时重置 然后首页打出广告:欢迎各大黑客暴力破解,本站登陆不设验证码,对,就是那么自信 XD |
98 dndx 2018-07-18 01:42:02 +08:00 |
99 yangqi 2018-07-18 02:13:38 +08:00 楼主最基本的尝试都没有搞清楚啊,你没法判断你的前端是正常用户还是机器,目前唯一的办法就是各种验证码。你搞再多的算法幺蛾子没用的。 “经过测试 10000 次内 md5 加密前端用时不超过 300ms, 用户察觉不到, 但是暴力破解的难道确增加了几千倍, 这意味这本来一个小时能破解的网站, 现在可能要一年才能破解” 现在的暴力破解是不停的提交登录请求来试出正确密码,瓶颈根本就不在计算能力,而是网络响应。你 10000 次 300ms, 破解的只需要照搬你的函数一样的,难度并没有增加,最多就是比之前慢了一点,和楼上说的服务器加延时并没有区别。 |
100 tangzhangming 2018-07-18 03:43:56 +08:00 简单的说,你压根没明白这个功能的痛点在哪儿 |