Popular 'provably fair' dice faucet box script... is hackable

[mfrks5ubKV]

Original script: https://github.com/coinables/Bitcoin-Faucet-Dice-Faucet-Box

So yes, it turns out that the dice script being used by a handful of faucets here can be brute-forced offline if you know the `Date` header sent from the server and the next hash.

Brute forcing the hash can take a couple of hours on one computer, that's a painful wait, but with even couple of extra spare computers I determined that the return on investment would be higher than mining bitcoin. So I added a tool which allows you to distribute the work on 1-1000 servers, which can bring the time down to a handful of minutes or even seconds.

Anyway, the script is poorly written by a novice coder who doesn't have a background or very deep understanding of cryptography, that's not a bad thing - everybody has to learn somehow. But placing your trust in a random third-party script that you got off the internet... maybe not the best thing to do.

I am interested in auditing more 'provably fair' systems, feel free to get in-touch via GitHub.

Questions?

[mavenraven]

impressive research and respectable paper, with code to boot

don't have server farms, so will not run it

the question is: have you contacted the original author, have you proposed an improvement of his system (like: stop relying on date, or stop sending it), a pull request, etc?

[coinableS]

https://github.com/coinables/Bitcoin-Faucet-Dice-Faucet-Box/issues/1

I've sent the white hat a donation to his address, even though he found it necessary to insult me. That aside, this is a perfect example of how open sourced projects improve.  Someone finds a flaw and share it openly to the community so it can be improved upon.   

"The algorithm claims to be 'provably fair', but I have a feeling that the author didn't fully grok the theory behind it because there's no way to input client-side random into the roll so the server can still manipulate which numbers it picks..."

This is unnecessary. Maybe if it were a real gambling site it would help users feel more comfortable, but not for a simple faucet game. The server displays the hash BEFORE the user sets their target or places their bet.  This would imply that the server would have to know what bet the user places ahead of time, which is not possible.

"Yup, the search space contains about 22 billion entries with a known starting seed, at 250 chrono-ticks per second (equivalent to 2.5m SHA-1 digests) it can take several hours to brute force the hash with a single thread, which is a lot of spare time to be looking at the computer doing nothing, so during that time I wrote a work distributor that allowed me to spread the load across an arbitrary number of servers over SSH in addition to my local machine.

Now with a few more servers I can reduce the brute force time from 3 hours to 30 minutes, and with a few more it can be done in a handful of minutes. However, given the miniscule amount you can win from these sites by guessing the right number, the CPU power required to get anywhere quickly is cost-prohibitive."

A simple fix to the salt brute-forcing would just be widening the space from where the salt is generated, as it already takes dozens of machines to brute-force my existing simple algorithm. I will be updating the github repo with the new algorithm shortly.

[FaucetRank.com]

Check out: https://github.com/HarryR/forceitbox

Original script: https://github.com/coinables/Bitcoin-Faucet-Dice-Faucet-Box

So yes, it turns out that the dice script being used by a handful of faucets here can be brute-forced offline if you know the `Date` header sent from the server and the next hash.

Brute forcing the hash can take a couple of hours on one computer, that's a painful wait, but with even couple of extra spare computers I determined that the return on investment would be higher than mining bitcoin. So I added a tool which allows you to distribute the work on 1-1000 servers, which can bring the time down to a handful of minutes or even seconds.

Anyway, the script is poorly written by a novice coder who doesn't have a background or very deep understanding of cryptography, that's not a bad thing - everybody has to learn somehow. But placing your trust in a random third-party script that you got off the internet... maybe not the best thing to do.

I am interested in auditing more 'provably fair' systems, feel free to get in-touch via GitHub.

Questions?

Can you prove it practically because so many users are already using this script and nobody claimed anything wrong with this script . If you found any flaw in this script than tell to original coder so he can fix that flaw .