根据 Hashcash 做的反机器人 CC 攻击算法

我想了想还是单独贴出来让更多的人看到，大家一起看一下可行性以及是否存在问题。

体验可以到这里 http://blog.eqoe.cn/ 在右边进行搜索

我们可以看到点击搜索的时候客户端发送了 3 次请求。

第一次：提交 Get 请求，服务器返回 error=1 表示该关键词没有被内存缓存，需要 Hash 验证
第二次：提交 Get 请求，获得一个 TOKEN，然后客户端在此 TOKEN 后增加数字，直到这个字符串 SHA1 值的前4位为0（服务器需要保证 TOKEN 与每个 IP 地址对应）

客户端计算 Hash 示例代码

var tk = "获得的TOKEN内容";
var str = 10000;
var lasthash = "";
while(lasthash.indexOf("0000") != 0){ //如果 lasthash 前4位不是0则持续循环
    str++;
    lasthash = sha1(tk+str.toString()); //把 Token 和 数字拼接起来
}; //经过多次测试 PC端计算大约需要1-3秒 移动端需要2-5秒

第三次：我们将 tk str 以及要搜索的内容 POST 到服务器上，服务器识别 TOKEN 与 IP 地址相符，并且与 str 合并之后的 sha1 结果前4位为0，服务器返回搜索结果，否则提示客户端进行重试。

如果需要的话你可以对我的 blog 进行压力测试，别打太狠就行。。。

假设使用 C 语言制作客户端计算一个 Hash 需要 2 秒，攻击者使用 16 核电脑和若干代理IP，那么你的服务器每秒只会收到 8 个以下的请求，这种算法应对一般的攻击应该可以无压力的防住吧？

lecher

2014-12-24 12:35:45 +08:00

这个仅仅就是防单机单ip发起的cc。
但是就像binux大神说的，单机多ip代理无限构造0000+随即字符串，根本不用算正确的请求，就可以打死了。
和打有验证码的一个道理，不用突破到数据库处理层面，直接多ip代理打服务器，服务器光是计算hash和缓存hash的结果就要算到死了。

也不一定是打搜索页面，比如打注册账号验证用户名是否有效和邮箱是否有效的请求，这个一般网站为了一致性，缓存找不到的一定回去数据库查的，而校验用户名有效性这个请求，一般都没有做校验就直接打到数据库了。多ip代理打过去，服务器的压力要比单机的压力大一些。

zhicheng

2014-12-24 23:25:22 +08:00

hashcash 必然是有效的，要不然 bitcoin 早就被攻击死了。
LS们讨论的大量IP+0000随机数的不太现实。。。
sha1 大部分语言 100K/s hash 轻轻松松的。但你不太可能有那么多 IP 地址。或者说，如果真有这么大的资源，也无所谓攻击这个地址了，静态页面都能打死了，光流量服务器都撑不住。完全不在一个讨论层次上。
小规模的单服务器网站，直接在存 session 在页面渲染出挑战值就可以。
大规模的多服务器网站，可以用 hmac(ip + timestamp) 做挑战值，验证写到 nginx 里，性能损失可以忽略。

根据 Hashcash 做的 反机器人 CC 攻击算法

客户端计算 Hash 示例代码

根据 Hashcash 做的反机器人 CC 攻击算法