感觉“工作量机制证明”甚至在包括登录验证、抢购、防业务层DDOS等方面上挺有用哈

Sly

客户端和服务器通信时，用各种工作量证明算法：

客户端会从服务器上领一个任务，这道题需要16核主流CPU花费比如接近1s才能碰撞出结果。
客户端像服务器提交请求的时候，必需包括计算结果。
而服务器验证结果是否正确就很容易了，计算量非常少。

这不直接把业务层面的网络暴力破解甚至DDOS攻击等都给防住了。因为每个请求必需消耗客户端算力，也就没法制造很大的并发请求了。
服务器只要验证答案错误，直接抛弃请求不做回应。

当然工作量具体是多少，要根据业务情况灵活设计。
碰撞时间虽然有长有段，但是平均时间是可以预计的，所以仍然可以作为防暴力工具的方式。

感觉这办法在登录、抢购等方面超级无敌，防业务层DDOS利器。

这种办法是还有什么问题么？（本帖不断完善中，让这个机制更有针对性）

相当于把业务层攻击（比如抢购脚本、暴力登录脚本）等纯粹变成传统流量级的DDOS，从而依赖ISP和防火墙策略去解决。

皇冠3.0L

电脑16核主流CPU花费1s才能计算出结果，
那手机用户登录不是直接炸了

goat

ddos是见洞就洪水漫灌，难道还指望每滴水先取介绍信然后等门卫放行吗？

登录/抢购瓶颈是人还得读取ui - 理解内容 - 输入，这里干得过机器？后台多一道计算？人方难道不用算了？

Sly

皇冠3.0L 发表于 2025-10-3 12:37
电脑16核主流CPU花费1s才能计算出结果，
那手机用户登录不是直接炸了

正文倒数第三段第一句话。

皇冠3.0L

Sly 发表于 2025-10-3 12:41
正文倒数第三段第一句话。

有没有可能，攻击者根本不会去跑运算，
一秒有一万个IP地址给你塞一万个错误答案，
但你还要一个个去验证这些答案是否正确。

Sly

皇冠3.0L 发表于 2025-10-3 15:25
有没有可能，攻击者根本不会去跑运算，
一秒有一万个IP地址给你塞一万个错误答案，
但你还要一个个去验证 ...

验证答案的成本很低（就和挖矿一样）
但是攻击者的攻击频率就下来了

比海量攻击者+海量频率好吧，至少解决了后者

fcs15963

Sly 发表于 2025-10-3 15:29
验证答案的成本很低（就和挖矿一样）
但是攻击者的攻击频率就下来了

攻击者只要回传一个错误答案，他依然完成了攻击，因为这边并没有拒收，反而接收并进行了验证。
至于握手失败，DDOS本来就不需要握手成功。

Sly

fcs15963 发表于 2025-10-3 15:54
攻击者只要回传一个错误答案，他依然完成了攻击，因为这边并没有拒收，反而接收并进行了验证。
至于握手 ...

那种连业务级别都不涉及的DDOS，可能档次低了点。

xy.

1. 服务器验证结果是否正确就很容易了，计算量非常少

复制代码

少在哪

xy.

Sly 发表于 2025-10-3 16:06
那种连业务级别都不涉及的DDOS，可能档次低了点。

涉及业务的一般叫 cc, 相对来说档次比较低

Sly

xy. 发表于 2025-10-3 16:08
少在哪

多在哪

xy.

Sly 发表于 2025-10-3 16:10
多在哪

我直接发随机数据, 计算量接近 0, 你服务端至少要验一次吧?

fcs15963

Sly 发表于 2025-10-3 16:06
那种连业务级别都不涉及的DDOS，可能档次低了点。

我又想了想不对啊，DDOS的时候服务器面对的是成百上千万的肉鸡，就算每台肉鸡算一秒服务器也还是顶不住啊。 DDOS的时候服务器卡的延迟早就不止一秒了。

Sly

xy. 发表于 2025-10-3 16:12
我直接发随机数据, 计算量接近 0, 你服务端至少要验一次吧?

无效数据判定的难度也不大，可以将攻击尽可能的变成纯粹的流量攻击（业务级别都不涉及的DDOS），不涉及业务逻辑层去消耗算力来计算。

毕竟比如HTTPS本身也是加密的，本来也要判定一次。

Sly

fcs15963 发表于 2025-10-3 16:21
我又想了想不对啊，DDOS的时候服务器面对的是成百上千万的肉鸡，就算每台肉鸡算一秒服务器也还是顶不住啊 ...

那玩意总感觉是靠硬件防火墙来抵挡吧，而不是真正跑业务的服务器。

毕竟相当于应对海量无效数据包了，纯粹拼ISP和防火墙的实力。
至于方法……比如，针对黑名单IP，直接拒收？（还是那些传统的阻断方式）

xy.

SSL/TLS 早都是硬件加速或者 SSL offloading, 本来就没有计算负担
你说的这些都和 DDoS 防御是两个不同维度, 流程还没走到你考虑的这些东西呢

Sly

xy. 发表于 2025-10-3 16:29
SSL/TLS 早都是硬件加速或者 SSL offloading, 本来就没有计算负担
你说的这些都和 DDoS 防御是两个不同维度 ...

我说的这些本来就是应对业务层面的暴力攻击的，比如暴力破解Wi-Fi密码，暴力抢购脚本等等。

至于一下子1亿台肉鸡向服务器频繁发送常规数据包然后直接耗死的方式，这应该是ISP和防火墙应对的事情吧。
包括直接安排100个无线网卡，配合程序去消耗尽AP的通信能力，这也不是讨论的范畴（还不如直接上无线屏蔽仪）。

xy.

Sly 发表于 2025-10-3 16:31
我说的这些本来就是应对业务层面的暴力攻击的，比如暴力破解Wi-Fi密码，暴力抢购脚本等等。

至于一下子1 ...

啊?

Sly

xy. 发表于 2025-10-3 16:36
啊?

对的，一开始没有说清楚，在和你们的讨论过程中，也可以不断完善这个算法的目的。

这句话要结合全文来看好吧……

oolmfoo

業務DDOS 有例子嗎?
暴力破解密碼,不也是流量攻擊?

YsHaNg

Sly 发表于 2025-10-3 08:38
对的，一开始没有说清楚，在和你们的讨论过程中，也可以不断完善这个算法的目的。

这句话要结合全文来看 ...

那你也更新一下吧

Sly

YsHaNg 发表于 2025-10-3 17:12
那你也更新一下吧

早就更新了，差不多1楼已经说清楚了。

Sly

oolmfoo 发表于 2025-10-3 17:03
業務DDOS 有例子嗎?
暴力破解密碼,不也是流量攻擊?

比如抢购商品、查询/抢购火车票。
这玩意涉及业务（因为要判断商品量和建立订单）

xy.

Sly 发表于 2025-10-3 16:38
对的，一开始没有说清楚，在和你们的讨论过程中，也可以不断完善这个算法的目的。

这句话要结合全文来看 ...

一个是服务端计算成本
一个是用户体验问题: 我做各种限流, 风控之类的初衷一定是想服务正常请求的, 如果不想服务, 我直接拔电就完事了. 这些东西都是很容易并行化的, 专业攻击者可以用大量设备摊平计算成本, 最终对于普通用户的伤害一定是大于等于专业攻击者的.

mustleave

”而服务器验证结果是否正确就很容易了，计算量非常少。“

能有多 少?  能大概举例说一下如何做到最少嘛?
只要验证结果的计算量稍微多一点就扛不住DDOS, 服务级别的DDOS你不能指望ISP(为什么指望ISP?顶多就给限速限pps,正常业务也受影响)和防火墙(防火墙对计算结果正确与否不感知).

Sly

xy. 发表于 2025-10-3 17:19
一个是服务端计算成本
一个是用户体验问题: 我做各种限流, 风控之类的初衷一定是想服务正常请求的, 如果 ...

对普通用户也没啥伤害吧，跑工作量也是客户端程序后台跑，哪怕是移动设备，用户输入信息的时间也跑完了。
至于电量，1秒钟（甚至几秒钟）可以忽略不计吧。

xy.

Sly 发表于 2025-10-3 17:22
对普通用户也没啥伤害吧，跑工作量也是客户端程序后台跑，哪怕是移动设备，用户输入信息的时间也跑完了。 ...

普通用户手里的算力不可能大于专业攻击者

mustleave

Sly 发表于 2025-10-3 17:15
比如抢购商品、查询/抢购火车票。
这玩意涉及业务（因为要判断商品量和建立订单） ...

这几个例子都不太合适
如果引入工作量证明, 那不同的客户端计算能力有差别反而回导致过程不公平, 我用高配PC来抢和别人用手机是有优势的, 这种机制反而真正助长了拥有强大硬件专门抢单的黑产.

Sly

mustleave 发表于 2025-10-3 17:20
”而服务器验证结果是否正确就很容易了，计算量非常少。“

能有多 少?  能大概举例说一下如何做到最少嘛?  ...

参考挖矿的证明

就是为了DDOS攻击少干涉到业务层面，而变成纯粹的流量攻击，那就是传统的防护方式了（这也是没办法绕开的）。

比如抢票脚本就是涉及到业务层了，需要后端反复查票和验证用户身份。

Sly

mustleave 发表于 2025-10-3 17:24
这几个例子都不太合适
如果引入工作量证明, 那不同的客户端计算能力有差别反而回导致过程不公平, 我用高 ...

本来就是增加黑产的投入成本。

现在的思路不也是如此么。

对于不计成本的攻击者，啥办法都不管用，除非物理把他灭了。