friendly-pow

Yeah, WebAssembly have i64/u64 types as first class citizens unlike JavaScript which should emulate it or use BigInt which drastically slower than native 64-bit types. That's why crypto algorithms got a lot of speed benefits. AssemblyScript also show this. See this: https://github.com/FriendlyCaptcha/friendly-pow https://github.com/hugomrdias/rabin-wasm

It gets worse for a determined attacker. The "difficulty" on that page seems to be 136, corresponding to ~131000 hashes of blake2b if I'm understanding the documentation right [1] There are ASICs for crunching blake2b designed for mining siacoin. One ~$2000 card [2] can do ~4 trillion hashes, or 30 million captcha solves, per second [1] https://github.com/FriendlyCaptcha/friendly-pow [2] https://www.miningstack.com/products/dragonmint-b52

The default difficulty is set to a difficulty that makes sense on websites that have a varied audience (which includes some ancient browsers on old devices). The solver runs in WebAssembly and is really really fast (~4M hashes per second) - but not every browser supports WASM yet (around 0.3% empirically). The JS fallback is around 10 times slower (more in 5+ year old browsers) - for those users you want at least a decent solve time too. For Gitlab's audience the difficulty can probably be increased a lot - it all depends on the website and usecase. I'm sure the JS fallback's performance can be improved (it involves a lot of operations on 64bit ints that need to be represented as two numbers in JS), happy to accept PRs [1] :) [1]: https://github.com/FriendlyCaptcha/friendly-pow/blob/master/...