Online Highscore TCP or HTTP

[AlexAUT]

Hey,

Currently I'm planning the online highscore for my little Game Kroniax. I already had one in the past but lost the source code  . So I have two options now, maybe an experienced network Developer(Binar can help me out which is the better way to go...

• Code a SFML application, install it on my server, connect via TCP and send the highscore / new times
• Do it via HTML/Php/MySQL (Webserver). I found a tutorial about this some time ago. But I have no idea if this would be easy to implement with sf::Http (on the clientside)

AlexAUT

[Laurent]

I'd do the second one. Whenever you need to access public internet, HTTP-based solutions are a good choice because you know you won't get annoyed by firewalls or whatever.

It's really easy to implement:

std::string parameters = "name=" + std::to_string(name) + "&score=" + std::to_string(score);

sf::Http host("http://www.your-site.com");
sf::Http::Response response = host.send(sf::Http::Request("send-high-score.php", sf::Http::Request::Post, parameters));

if (response.getStatus() == sf::Http::Response::Ok)
{
    if (response.getBody() == "ok")
        std::cout << "high score successfully added" << std::endl;
    else
        std::cout << "error, server responded " << response.getBody() << std::endl;
}
else
{
    std::cout << "HTTP request failed with status " << response.getStatus() << std::endl;
}

$name = $_POST['name'];
$score = $_POST['score'];

... open database and write new record ...

if (success)
    echo 'ok';
else
    echo 'some error message';
 

This is just for the idea; this code would need more checking and some encryption to avoid people hacking into the high score table.

[AlexAUT]

Thanks Laurent for your quick and detailed answer!

I will give it a try, learning PHP/MySQL again 


Have you any idea how to encrypt the data? like a password?


AlexAUT

[Laurent]

I don't have much experience with data protection, but I guess a simple solution would be to send a checksum of the name + score, and check it on server side. Of course, this works only if you keep secret the algorithm, or at least a part of it (like a secret string added to the data before computing the checksum).

You should find much more interesting and complete answers with Google. One random example: http://stackoverflow.com/questions/73947/what-is-the-best-way-to-stop-people-hacking-the-php-based-highscore-table-of-a-f

[eXpl0it3r]

The only partially secure way would be to upload the whole game play and simulate it on the server to make sure the score is possible.

[dwarfman78]

Instead of php, you can consider using nodejs + restful module (express) + mongodb (mongoose) which is lightweight and full of hype nowadays. (you might consider using passport for authentication too)

I'm currently trying to release enough free time to do such things for my games. I'll keep you posted if i succeed.

[AlexAUT]

Thanks for you suggestions, I went with Laurent's advice and it works really well (PhP/MySQL with sf::Http). Thanks Laurent for the hint 

About security, I think it's useless to implement a complex system... You can crack it anyways, except the way exploiter described, but I think this would be an overkill... 

AlexAUT

[Peteck]

About security, I think it's useless to implement a complex system... You can crack it anyways, except the way exploiter described, but I think this would be an overkill... 

AlexAUT

Trust me, Laurent suggestion is the right way to go. As a professional web developer I use this approach alot across different API's. Actually it's the most common way to secure a payment gateway from being hijacked.

Before one can crack your system, one will need to know your secret key. And for type of HASH, go with a SHA-2 hash and then you'll be good to go :-)

But you can expand this approach alot. You could reverse the whole HASH and so on to make it more difficult for one to understand what you're doing in your code.

[Nexus]

Encryption and hash alone aren't enough, replay attacks are still possible. Even then, as long as the private key is stored on the computer, the hacker can get access to it in principle. That's also described in Laurent's link, by the way.

So it's really a trade-off between how much effort you want to spend, and what hacking effort you expect... For a simple game where high score exists for the honor , I'd probably only introduce basic measures against script kiddies who want to modify the transmitted score.

[eXpl0it3r]

Trust me, Laurent suggestion is the right way to go. As a professional web developer I use this approach alot across different API's. Actually it's the most common way to secure a payment gateway from being hijacked.

Before one can crack your system, one will need to know your secret key. And for type of HASH, go with a SHA-2 hash and then you'll be good to go :-)

Web development and "binary" development are two very different things and need a completely different approach in regards to security measurements.
While some secret hash on your web server might be "okay" way to go, you forget that one can only optain the hash, by accessing the server somehow. But when it comes down to creating a binary that holds the secret key, it's a whole different story.

The first attack angle would be, to just open the binary in a text/hex editor and go over the characters that might represent a continuous string. If the key has been saved in the source like std::string s = "SecretKey"; then the key can in nearly all cases be found in plain text in the binary. Your "ok" method suddenly became useless.

A second way to go, if the first wasn't already successful is go and capture the network traffic. This will most likely be needed anyways, since one needs to figure out the communication protocol. Since they are simple HTTP requests, it's very, very easy to read the whole traffic. If the key is sent to the server you'll immediately get it here. - Maybe one would even start with this step, since it's a lot easier.

If that was not satisfying enough, there's always the possibility of disassembling the whole things or attaching a debugger etc. With enough skills, knowledge and time "client side" security can always be cracked.

But you can expand this approach alot. You could reverse the whole HASH and so on to make it more difficult for one to understand what you're doing in your code.

Obfuscation is a good thing and while it won't increase the actual security, it will still prevent low-skilled people from "cracking" things.

If you're further interested in that topic, you might want to talk to the guy(s) behind OpenHexagon, since they had to find a way to make it somewhat secure and unfortunate enough there was one guy that felt the need to play quite the kid and spam their highscore database with junk etc.

[Peteck]

As for securing for replay do some IP checking and time checking.
For the private/secret key, I would make a function that manipulates the key before it'll be used and delete the manipulated key from memory right after. I know this will not be totally secure, but it will be harder for the hacker to pull the key out.

And guys, please correct me if I'm wrong and if what I suggests can't be done. I'm just throwing out some ideas from the top of my head. But ye, if the hacker is skilled enough I guess mostly everything can be hacked.

[eXpl0it3r]

As for securing for replay do some IP checking and time checking.

Time checking against what? You know one could simply execute a replay attack from the same IP.

For the private/secret key, I would make a function that manipulates the key before it'll be used and delete the manipulated key from memory right after. I know this will not be totally secure, but it will be harder for the hacker to pull the key out.

That's a possible obfuscation and since you'll actually have to know the de/encryption algorithm for the saved key, you're forcing "hackers" to look at the code/asm. With a debugger and some asm knowledge this is however still rather easy to figure out - thing of all the serial keys algorithm that have been reverse engineered. But yes, for a simple game, this serves well enough I'd say.

[Peteck]

Time checking against what?

Well make some kind og algorithm that checks if the request is actually possible for one to do. If the same score request comes two times in a row. Thats suspicious, but actually possible. But the same score within 1 minute, well thats should not be possible (of course this depends on what game it is). I would use sessions to control this.

Also I would send a time value in the HASH that well check if the time of the request is okay. I know this will be really hard because of internet latency. But if we said the time just had to be within the set timeout on the server.