网络安全应用安全后端【免费下载链接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.项目地址https://gitcode.com/gh_mirrors/cap13/cap点击查看免费下载Cap 是一个免费、开源、可自托管的 CAPTCHA 替代方案。本文围绕其官方文档 docs/zh/guide/effectiveness.md 的核心论断展开Cap 不靠猜测谁是人类来拦截机器人而是通过**工作量证明Proof of Work, PoW与Instrumentation浏览器环境检测**两套独立机制把自动化滥用的成本抬到经济上无利可图同时让真实用户的体验保持快速且几乎无感。读完本文你将理解 PoW 的攻防经济学、为什么 Cap 默认采用抗 GPU 的 HashWX 协议、这两层验证在源码中如何实现以及如何在 cap-core 与 Standalone 中实际配置难度与协议。隐私与安全默认不追踪、默认防重放Cap 在隐私层面的设计是少即是多这一点直接写进了有效性文档默认不使用 Cookie也没有任何形式的遥测质询的签发与验证不依赖任何客户端状态存储完全自托管质询生成、验证、令牌签发全部发生在你自己的服务器上没有任何数据被收集或存储到中心化服务器默认内置重放防护和基于签名的质询令牌质询令牌是使用 HMAC 主密钥签名的 JWT客户端无法伪造或篡改参数难度、盐、过期时间详见 core/src/index.js 中generateChallenge的jwtSign调用。从源码结构看无状态是这套设计的根基capjs-core库本身不持有任何会话generateChallenge(secret, opts)每次调用都用crypto.randomBytes生成随机盐并把质询配置签进 JWTvalidateChallenge(secret, body, opts)则先用jwtVerify还原并校验载荷core/src/index.js。重放防护以可插拔回调consumeNonce(sigHex, ttlMs)的形式提供——库不绑定具体存储你可以把它接到 Redis 的SET NX EX、Cloudflare KV 或 PostgreSQL 唯一约束上实现真正的按需开启参见 docs/zh/guide/capjs-core.md 的重放防护一节。为什么选择工作量证明把猜谁是人换成让滥用变贵有效性文档开门见山承认一个事实任何 CAPTCHA 最终都能被破解——无论是通过 AI 识别图片、算法逆向与伪造指纹还是直接雇 CAPTCHA 打码平台人工解题。攻防双方因此陷入无休止的猫鼠游戏。Cap 的立场是真正的区别不在于能不能破而在于攻击者要付出多少成本。文档给出了一个很直观的经济学模型设想发送 10,000 条垃圾消息的成本是 1 美元潜在收益 10 美元这样有利可图。如果 Cap 抬高计算成本把发送这批消息的成本变成 100 美元垃圾消息发送者就要亏损 90 美元经济动机就此消失。这就是 PoW 的定位通过要求付出计算量来阻止滥用而不是依赖机器人不断学会模仿的人工验证手段。Cap 的工作量证明深受 Hashcash 启发其 instrumentation 质询则借鉴了 Twitter 和 YouTube 各自的自定义质询。从实现角度看这套成本论对应的是 core/src/index.js 里validateChallenge对解的校验每个提交的解必须满足powMatchesPrefix(sha256Bytes(salt nonce), target)任何错误解都会以invalid_solution失败攻击者无法靠猜通过。机器人要规模化地通过就只能规模化地消耗 CPU 去求解——这正是成本的来源。让 GPU 无用武之地从 SHA-256 到 HashWX作为通用 PoW 算法SHA-256 是合理的选择但它有一个致命弱点GPU 每秒能清掉的数量大约是 CPU 的 150 倍。GPU 用成千上万条通道同步运行同一个固定函数而机器人防护真正在意的指标恰恰是吞吐量——攻击者不关心单个质询要花多久只关心每小时能清掉多少个。因此新建的密钥默认使用 HashWX一个由 tevadorRandomX 与 HashX 的作者设计的抗 GPU 哈希算法。Cap 在 wasm/src 中内置了其官方 WebAssembly 参考实现并在 core/src/hashwx.js 中通过hashwxReady()懒加载编译。文档给出的吞吐量对比来自 tevador 的未公开 CUDA 实现RSW 行由 Cap 独立复现验证算法CPURyzen 3700X16 线程GPURTX 5060 TiGPU 优势SHA-25641 MH/s6150 MH/s~150xRSW26 H/s4400 H/s~170xHashWX2.8 MH/s5.8 MH/s~2x注意 RSW时间锁谜题也在表中它在延迟维度上很出色单个谜题内部的顺序平方无法并行但在吞吐量维度上输得很惨GPU 可以同时跑几千个互不相关的谜题优势反而高达 ~170 倍。RSW 已被弃用它仍然可以按密钥选用现有密钥也继续可用但不应再用于新的部署。HashWX 协议如何工作在 core/src/hashwx.js 中可以看到协议的完整实现脉络铸造服务端取 32 个随机字节作为质询Ccrypto.randomBytes(HASHWX_CHALLENGE_SIZE)再定一个难度d。没有密钥材料、没有预计算铸造就是一次随机读取加一次 JWT 签名——这也解释了文档所说HashWX 不需要密钥材料启动时也不用做任何准备。客户端求解客户端要找到一个 64 位 nonceN使得H(N) (2^64 - 1) / d其中H hashwx_make(sha256(C || u64le(N / n)))。每一块n个连续 nonce 共用一个生成出来的哈希函数。hashwxTarget()在源码中即U64_MAX / d的实现。块大小nCap 使用n 65536DEFAULT_HASHWX_NONCES_PER_HASH。参考协议给原生客户端用的是 463在浏览器里每一块都要通过WebAssembly.Module把函数重新 JIT 编译一遍更大的块能摊薄这部分开销。tevador 明确指出这个取舍每个函数覆盖的 nonce 越多协议就越容易被 JIT 编译的 GPU 内核追上在此取值下撑住抗 GPU 能力的是分支发散。服务端验证服务端根据C和提交的 nonce 对应的块索引重新算出种子hashwxSeed即sha256(C || u64le(block))生成那一个哈希函数运行一次再与目标比较。程序生成的开销大约只有 HashX 的 1/5这正是验证能保持在几十微秒的原因。核心实现在 core/src/hashwx.js 的verifyHashwxSolution。为什么 GPU 快不起来HashWX 的四个抗 GPU 特性均出自 tevador 的设计文档值得展开分支发散每个实例是 32 个程序每个程序都是一个循环以 1/2 的概率跳回自己的开头算下来每次哈希正好 256 次分支。CPU 上这只是几次分支预测失败GPU 上它会把一个 warp 拆成若干发散路径只能一条接一条地执行。刻意不对齐的 16 KB 暂存区CPU 把它放进 L1用乱序执行掩盖 34 个周期的延迟GPU 只能放在由 L2 支撑的本地内存里延迟约 100 个周期且大多数 GPU 架构还得把两次相邻读取拼起来才能模拟不对齐读取。深/浅源寄存器列表源寄存器取自交错排列的浅列表和深列表CPU 平均要处理 2.75 次相互依赖的读取GPU 解释器只能按深列表特化因为约 95% 的情况下一个 warp 里至少有一个线程在跑深程序于是每次都吃下完整的 6 次依赖读取链。受限指令集指令集被限制在 WebAssembly 1.0 范围内64 位乘、加、减、XOR、OR、循环移位和移位6 位立即数正是这一点让同一套算法能在浏览器里跑起来。成本服务端与客户端文档给出了 Apple M3 单核心上validateChallenge实测的服务端成本200 次铸造 40 次验证取中位数协议铸造验证合计HashWX1 个质询14 µs40 µs54 µsHashWX4 个子质询默认20 µs129 µs149 µsSHA-25650 个质询难度 44 µs83 µs87 µsRSWt 75,0001522 µs14 µs1536 µs单个 HashWX 质询是三者中往返开销最低的默认的四个子质询约 150 µs只有 RSW 的十分之一RSW 每次签发都要做四次真正的模幂运算。难度不影响服务端成本无论找到解有多难验证每个子质询都只需算一次哈希——这一点与 core/src/hashwx.js 中verifyHashwxSolution只执行单次hashwx_exec的实现完全吻合。为什么默认拆成 4 个子质询单个质询的求解时间服从指数分布让它像抽奖同样的难度一位访客 30 毫秒解完下一位要三秒。拆分把总难度d均摊到 4 个独立子质询上源码见mintHashwxChallenges中的each Math.max(1, Math.round(difficulty / count))让求解时间更均匀。文档在 8 核 M3 上用正式版 Chrome 实测每组 72 次求解两种难度调到相同中位数1 个质询d 1,330,0004 个子质询d 1,000,000中位数536 ms490 msp901447 ms778 ms72 次中最慢2378 ms1490 ms对给定的难度拆分并不改变攻击者要付出的代价预期工作量都是d次哈希改变的是分布形状单个质询的中位数只有均值的 0.69四个子质询把中位数推到均值的 0.92 左右长尾也随之缩短。验证组件自身的开销很小——worker 每 16 毫秒检查一次是否该停止HASHWX_YIELD_MS 16见 widget/src/src/worker.js这决定了子质询之间交接的最长时间。浏览器引擎与移动端表现HashWX 的 wasm 构建速度约为原生的 60%。三大引擎在单个 worker 上相差无几所有核心跑满时 Safari 会落后同一台 M3、同一次测试、各浏览器处于无头或前台引擎1 个 worker8 个 worker解释执行回退Chrome 153440 KH/s2050 KH/s94 KH/sFirefox 156420 KH/s1850 KH/s105 KH/sSafari 27.2410 KH/s1480 KH/s105 KH/s调难度时要以 Safari 为准d 1,000,000 时 Chrome 上平均约 0.5 秒Safari 上约 0.7 秒。自行测量时务必使用各浏览器的正式发布版并让标签页保持在前台——Playwright 自带的 Firefox 跑任何 WebAssembly 负载都比正式版慢 36 倍后台标签页则可能被调度到能效核心上让数字直接减半。移动端BrowserStack 真机默认配置每台 15 次求解Vivo 30 次每轮从刚加载的页面开始设备系统全部核心中位数最慢Galaxy S24Android 141238 KH/s1.1 秒1.8 秒Pixel 9Android 15837 KH/s1.4 秒2.0 秒Pixel 6Android 12746 KH/s1.9 秒2.4 秒iPhone 15iOS 17未测1.9 秒4.3 秒Redmi Note 11Android 11456 KH/s2.4 秒4.8 秒Vivo Y21Android 11316 KH/s5.9 秒11.0 秒每次求解都包含两次到测试服务器的往返各设备中位数 80190 ms。入门级 Android 手机的耗时约为 M3 台式机的十倍——如果你的流量以移动端为主请调低难度求解时间与难度成正比500,000大约能让表中每个数字的求解部分减半。此外没有 WebAssembly 的客户端根本解不了 HashWX会直接拿到错误需要支持它们时应改用有纯 JS 回退方案的 SHA-256 PoW回退求解器实现见 widget/src/src/worker.js 的solveFallbackiPhone 上验证组件需要 iOS 15 或更高版本。与 Instrumentation 质询协同付出 环境工作量证明证明的是付出客户端必须消耗 CPU 周期寻找哈希但它无法证明计算发生在真实浏览器里——攻击者可以用脚本直接跑求解器。这正是 Instrumentation 质询的用武之地每次请求时服务端生成一段独一无二的 JavaScript 程序core/src/instrumentation.js 的generateInstrumentation在访问者浏览器中执行后把答案发回由服务端对照预先并行跟踪的期望值校验在接受令牌前确认对方处于真实浏览器环境。它的核心机制值得展开主计算链多个整数变量以随机种子值初始化经过约 20 轮随机化操作不断变换包括按位 AND/OR/XOR/NAND、原型链技巧fnHelper中的构造函数原型篡改以及基于 DOM 的运算domHelper向页面追加一棵元素树沿树回溯累加数值最后移除。为什么用 DOM 操作纯算术运算在非浏览器环境里直接运行这段 JS 就能复现DOM 操作做不到至少无法低成本地做到——构建真实元素树、通过排版引擎读取数值、再拆除它们触及的是非浏览器运行时常常只做桩实现、实现得不正确或出于性能跳过的那部分。质询因此很难在真实渲染引擎之外被重放。自动化浏览器检测可选开启blockAutomatedBrowsers脚本会运行 realm 逃逸检测与行为检测headless Chromium 标记、webdriver 属性、window/document上的自动化框架注入标记等识别 Playwright/Puppeteer/Selenium 等。不过文档如实说明这些检查并非万无一失即使是 Turnstile 这样的商业闭源 CAPTCHA攻击者也能用打过补丁的隐身浏览器绕过。执行环境所有检查都在 iframe 内运行通过postMessage把答案发回父页面。服务端通过verifyInstrumentationResult校验返回的state是否与expectedVals完全一致core/src/instrumentation.js。两者互补而非冗余PoW 抬高付出维度的成本Instrumentation 验证环境维度的真实性在两个独立维度上抬高滥用成本。面对有决心的攻击者单独任何一个都不够但同时攻破两者就难得多。同样重要的是文档的告诫Instrumentation 并非万无一失不建议用它替代工作量证明——在没有 PoW 的情况下攻击者用真实浏览器就能低成本地批量通过这类质询。局限与边界HashWX 防不住什么与 RSW 防不住的是同一件事定制芯片。专门为 HashWX 打造的 FPGA 或 ASIC 仍然会赢过 CPU。对刷 CAPTCHA 来说这笔账通常算不过来ASIC 的一次性工程费用高达数百万美元但这终究不是密码学层面的保证。它同样拦不住人工打码农场而且永远拦不住——工作量证明抬高的是每个请求的成本不是人工的劳动。正确姿势是把 HashWX 与 instrumentation 质询搭配使用让攻击者还必须提供真实的浏览器环境。实战在哪里配置难度与协议cap-coreformat-2 API 手动启用 HashWX在 docs/zh/guide/capjs-core.md 中cap-core 的默认仍是 SHA-256 PoWHashWX 需要通过 format-2 API 手动启用import { generateChallenge, validateChallenge } from capjs-core; const SECRET process.env.CAP_SECRET; app.post(/api/challenge, async () { return await generateChallenge(SECRET, { format: 2, protocols: [hashwx, instrumentation], hashwxDifficulty: 1_000_000, // 可选这就是默认值 }); }); app.post(/api/redeem, async (req) { return await validateChallenge(SECRET, req.body, { consumeNonce }); });关键参数默认值与边界均来自 core/src/hashwx.jshashwxDifficulty客户端预期计算的哈希次数默认1_000_000合法范围[1, 1_000_000_000]hashwxChallengeCount拆分的子质询数默认4范围[1, 64]每多一个子质询验证开销约增加 20 µshashwxNoncesPerHash每个生成函数覆盖的 nonce 数默认65_536范围[1, 1_048_576]。HashWX 不需要密钥材料启动时也无任何准备第一次验证会编译内置的 WebAssembly 模块耗时几毫秒可在启动阶段调用hashwxReady()把这份开销从首个请求挪走。验证组件会自动检测 format-2 响应只需升级服务端即可。Cap Standalone按站点密钥切换协议在 docs/zh/guide/standalone/options.md 中HashWX 是新建密钥的默认协议且按站点密钥配置个别密钥可以用 SHA-256其余继续留在 HashWX 上在 HashWX 成为默认之前创建的密钥会保持原有设置直到手动更改。打开某个密钥的Configuration标签页在Challenge protocol下选择协议即可无需任何准备工作没有密钥对要生成也没有东西要持久化。难度由HashWX difficulty滑块控制客户端预期计算的哈希次数默认1_000_000有效范围50_000–5_000_000拆分为四个子质询。调高之前请先参考上文移动端测量结果。Instrumentation 质询在新建站点密钥时默认开启可在密钥配置中开关Attempt to block headless browsers 可阻止无头浏览器求解。较高的 instrumentation 混淆级别会显著降低生成吞吐量除非需要更强混淆建议保持在级别 3obfuscationLevel默认值1–10 可选参见 docs/zh/guide/capjs-core.md 的 Instrumentation 一节。延伸阅读CAPTCHA 与转化率质询摩擦对注册量的代价以及低摩擦机制为何在转化率上更优2026 年最佳 CAPTCHA 替代方案与其他机制Turnstile、hCaptcha、FriendlyCaptcha、ALTCHA 等的横向对比HashWX 工作量证明抗 GPU 协议的完整设计与测量细节Instrumentation 质询第二层验证的机制与局限Core 无状态服务端库generateChallenge/validateChallenge的完整 API 与无状态部署模式Cloudflare Workers、BunStandalone 配置选项环境变量、速率限制、Redis/Valkey、健康检查与 HashWX 滑块赞分享网络安全应用安全后端【免费下载链接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.项目地址https://gitcode.com/gh_mirrors/cap13/cap点击查看免费下载相关推荐Cap 反机器人有效性解析proof-of-work 与 instrumentation 如何让滥用变昂贵Cap 反机器人有效性解析proof of work 与 instrumentation 如何让滥用变昂贵 Cap 是一个免费、开源、可自托管的 CAPTCH网络安全应用安全后端深入解析 Cap 工作原理基于 SHA-256 工作量证明与 instrumentation 的自托管 CAPTCHA深入解析 Cap 工作原理基于 SHA 256 工作量证明与 instrumentation 的自托管 CAPTCHA Cap 是一个免费、开源、可自托管的网络安全应用安全后端Cap 防机器人有效性解析为什么 Proof-of-Work 与 Instrumentation 的组合能抬高滥用成本Cap 防机器人有效性解析为什么 Proof of Work 与 Instrumentation 的组合能抬高滥用成本 本篇指南围绕 Cap一个免费、开源、网络安全应用安全后端上一篇GEMMA全基因组关联分析工具免费高效的遗传数据分析终极指南下一篇Nuclide工作集模板库框架特定配置快速应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考