11–20 of 47 posts
This talks about a "proof of work" system to mitigate DDoS. What's the "hello world" of such a system look like? It came up in a CTF recently and I had no idea where to start.
This is some old code, based off of the hashcash algorithm, that prototypes protecting DNS servers using a proof of work (also UDP). https://github.com/jevinskie/SlothNS/blob/master/pow/pow.c#L...
Sorry to nitpick but UDP seems like the wrong protocol for authentication. TCP is connection oriented. It's a better choice for logging in, refreshing a server list or any transaction where reliability is more important than latency. Most online multiplayer games use both TCP and UDP for this reason.
As for encryption, of course you should always use it when transmitting sensitive data. For a game where the client has no control over the state of the world and all packets are at the discretion of the server (`move here`, `click that`, etc.), encryption might be overkill. The source port value (first 16 bits of a UDP packet) can be used to identify the source of a packet and associate it with a client's server side session. But I'm not saying that encryption is a bad idea (it never is); it just depends on how much you can afford.
[1] https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...
> ...if some artifact within your game costs $20K+ of real-world dollars – you should start thinking about [encryption] seriously. In these cases, game account becomes as important as (and for quite a few people out there – much more important than) a bank account. Which carries all the security implications of the bank, including (but not limited to) encryption. Sorry to nitpick but UDP seems like the wrong protocol…
> ...if some artifact within your game costs $20K+ of real-world dollars – you should start thinking about [encryption] seriously. In these cases, game account becomes as important as (and for quite a few people out there – much more important than) a bank account. Which carries all the security implications of the bank, including (but not limited to) encryption. Sorry to nitpick but UDP seems like the wrong protocol…
I'm not sure how realistic a threat this is. Most likely crypto just helps obfuscate the game to make cheating/RE a bit harder.
> ...if some artifact within your game costs $20K+ of real-world dollars – you should start thinking about [encryption] seriously. In these cases, game account becomes as important as (and for quite a few people out there – much more important than) a bank account. Which carries all the security implications of the bank, including (but not limited to) encryption. Sorry to nitpick but UDP seems like the wrong protocol…
I took it to mean that you might use UDP for doing stuff in game that might result in losing items. Like, I dunno, maybe an attacker on campus or on WiFi proxies your connection then makes you lose or drop expensive items. I'm not sure how realistic a threat this is. Most likely crypto just helps obfuscate the game to make cheating/RE a bit harder.
And, of course, the mother of all datagram encryption protocols - the IPsec suite (ESP, IKE 2). It works with IP packets, but it can be very easily repurposed for UDP.
This talks about a "proof of work" system to mitigate DDoS. What's the "hello world" of such a system look like? It came up in a CTF recently and I had no idea where to start.
Here's a really simple proof of work system: during connection, the server tells the client some randomly generated bytes and a number of bits, and then the client has to come up with a string whose MD5 hash (or whatever algorithm you want to use) has its first N bits match the first N bits of the bytestring that the server gave. It's easy for the server to adjust the difficulty of the proof-of-work: it just needs to…
It seam that the computation of a MAC or an encryption where the key serves as salt could prevent such cheating. But this computations are now hardcoded in the cpu which won't be the same proof of work for everybody.
Can someone please explain me as if I was 5 years old how the proof of work is performed ?
Your client will basically be working on passing the test for a predictable amount of time, dependent on the difficulty threshold.
The neat thing about this method is that although it takes a while to pass the test, it's very fast and easy to check if a test is passed. You'll simply ask the client for the client_adjusted_nonce which gets a value higher than 50,000 (or whatever difficulty threshold you choose). As the author has stated, you can adjust the threshold depending on the strength of the DDOS.
Can someone please explain me as if I was 5 years old how the proof of work is performed ?
Like Bitcoin, you can ask clients to find a hash of a string (in the format of, say, 'server_key' + 'random_number' + 'client_adjusted_nonce') with the value of the last four bytes being higher than say 50,000. You can increase the value until 0xFFFFFFFE, where only 1 in 4294967296 hashes would 'pass' the test. Your client will basically be working on passing the test for a predictable amount of time, dependent on th…
https://github.com/kocubinski/opentnl/blob/master/tnl/client...