I think you don't fully understand what mechanics is behind the API key trick. There is no such thing as temproary API key that lasts for a minute or even a second. That would not be secure at all. The API key is unique for every call.

Even better then! But regardless, you still have to have a library of keys to match it against. And ultimately, these kinds of things are not secure (granted, even servers are not fully secure, even with layers upon layers of proxying/IPS/firewalls), but they are more secure than a permanent API key. The user can still retrieve the key from the source, and use it to submit a false score, prior to your program submitting the score. Breakpoints are a wonderful thing sometimes.

It's not always a variable, you can make a complex trick to confuse the source. But even if there's a pure variable, it's not just about to change the value. You must know how to generate a proper API key because it is validated on the server side. So you must understand the key generation algorithm first.

Yes, I am aware. But any half-clever user will be able to guess at your algorithm after a few tries, even if they cannot reverse engineer it out of your code. If there is one thing that I have learned, it is never underestimate the cleverness of determined players. Just look at the modding community for Skyrim. That game has not been supported by Bethesda for years, yet determined players are releasing patches and mods for it almost continuously.

i dont think it is possible with C2 to create such a game.

It is. I have my development client running right now, and it works. Unless our server is down, then it just displays the background image and nothing else. Because our game client is worthless without the server application behind it, because all of the game logic is on the server. The client simply displays information and submits change requests.

I have to laugh some at all the people who think they can secure their HTML games without a server.

This post asks more or less the same question: and I have the same answer there.

Minifying helps, but it will not guarantee that your game will not be pirated.

gumshoe2029 exactly.

Just to make it more clear, I'd split it to three simple levels of security here.

1. No SSL, No API KEY

Any kid who fetch the URL, is able to send fake data.

2. No SSL, with API KEY

You need a solid JS knowledge and have a lot of patience to - let's call it - decrypt the minified JS code and understand the API KEY generation algorythm (which by the way might be way more complex than standard sha1(salt+data)) in order to send fake data. So 99.9% of kids are already filtered here.

3. SSL

The right way for securing the data transfer.

Kind of...

You have to think of security from a domain perspective, not an application perspective. In security there are five domains: confidentiality, integrity, availability, accountability and assurance of services.

A. SSL

Protects data from being accessed by anyone except you and your customer. (Except maybe the NSA who has internet trunk access and possibly SSL zero day vulnerabilities in hand). SSL falls under the confidentiality section.

B. API Key (HTTP sessions and cookies fall under this category also)

Ensures that the person who owns the account is actually the one who is talking to your server. (A form of authentication) API keys fall under the accountability section.

---------------------------------------------------------------------------------

So when you start combining things:

1. SSL + No API Key

You have a secure connection between you and each of your players, but you have no way to know which player is asking for which information in any given request.

2. No SSL + API Key

Assuming that your API key is very temporary (like a lifetime of only a minute or less) and regenerated frequently, you are likely to know which of your players is asking for information from your server at any given time, but without using SSL anyone who can get close to either your server or your user's local network can simply scrape the API key from the wire and submit as theirs.

3. SSL and API keys

The data between you and each of your players is secure and cannot be snooped, and you know which player is asking for information.

--------------------------------------------

However, none of this addresses the problem that the OP has, which is legit players who have both SSL and API keys submitting false data. All of the above only prevent OTHER players or hackers from pretending to be that player.

Like Ashley said, in raw JavaScript there is no way to prevent that, because your registered users have all of the SSL certificates and API keys necessary to submit data to your server, there is nothing stopping them from simply changing the data and submitting it to your server.

I know I probably sound like a broken record constantly saying, "You have to have a server side application," but it is not wrong. That is the ONLY way you can keep players from submitting false data (that I have found thus far).

For example, our API call: https://www.ravenheart.ca/dev0engine?op=moveFleet&fid={fleet_id}&pid={to_planet_id}&oid={to_orbital_id}

Let's say player 2, who is the owner of fleet #3 on planet ID 22 and in orbital 0 wants to move his fleet. All of this information is stored on our databases (which cannot be tampered with by anyone except my developers and the server).

If he submits a call like:

https://www.ravenheart.ca/dev0engine?op ... d=68&oid=2

The call will reply with an error, because I run all of the data through a series of checks on the server to ensure that the player actually owns the fleet, that the fleet exists, that the planet and orbital exist, etc. If any one of these checks fails, the user gets an error message and nothing changes on the server. They get the reply:[quote:26jx7d1m]{"2041":["Error: This fleet does not exist","You do not have this fleet in this planet's orbitals."]}

JS Minifying helps, but it does not take a lot of skill to see the debugger output all of the variables and simply identify which one is being submitted to your AJAX API and simply changing the value of that variable in the source at execution time.

You need my Not Quite Random plugin, —

This will be useful in the future.

The only way to prevent pirating, is to have all of your game logic on a server application. That way the client is just a dead pile of images without the logic to run it.

ho well thanks, I managed to use the plugin. Now I'm just afraid I wasted my time with dictionnaries ? We'll see.

Yea, JSON support is one of C2's weak spots. The plugins are far better.

I don't think there is. :-/

I think you need to use another coordinate, because all C2 arrays are inherently 3D.

Try array[x][y][0] or array[x][0][0]

But think about something : doing a website with C2 is not bot-readable so your pagerank on search engine will be super low.

ea, this is another oddity that I have found too.

Yea, it will not work. But people can still scrape usernames/passwords/scores/etc. from the data streams, therefore it is inherently insecure.

And when it comes to non-repudiation, they can just submit a hashed score of whatever they choose, because hashing algorithms are publicly uniform.

That was what I meant when I said:[quote:3sd403xd]Anyone with a wire shark and knowledge of which algorithm you are using can guess at your original information.

In malinga91 's original post, if I wanted to submit a false score to his hashed system, I would use the URL:

https : // domain . com / endpoint / ajax.php?xxxsdf=92323&verify=fda64db2c94f9b96ad316a858f1fac3974059d07ebf244fb01b5e53e9c87eb76

and because I have access to all of the JavaScript variables, including his "secret," I can submit a false score still, and his server will still accept it because it is not secure.

But SSL certificates are not free

They are now:

https://letsencrypt.org/

Our web portal and game client are secured via SSL/TLS with certificates from Let's Encrypt.

Up to that, I have figured out another non-ssl security trick for sending data which contains not only the hashing API key but also the encryption. I called this method a Super64encode (/decode) as it is based on Base64 algorythm but salted with two keys. I will be releasing it to public soon with TR_System plugin which is an extention to the native System. Not sure if I'll remember to post it here, but you may want to follow me on Twitter or just check my blog from time to time. I should post it within two weeks or so.

I use a scheme like this too, but that does not protect against falsified data. The problem with all of these schemes is that the protections can simply be removed on the client side.

Someone has cheat on my game. using cheat engine.

You don't need a cheat engine to hack HTML5 games. A simple debugger like Firebug will do fine.

So your main goal is non-repudiation of the scores. SSL/TLS is not going to help with non-repudiation.

Because the SSL certificates are handled by the browser, and so the web application (and the corresponding debuggers) is technically behind the SSL security wall, so people will still be able to submit false scores, and your server will continue accepting them.

The only way that you are going to achieve this is to move all of your scoring logic onto a server application. Then the only power the client has is the power to submit requests for an action to happen. Then you can do all of your checks server-side, and if the score is illegitimate, then you can just send them back a nice error message.

Rule Number One of game development: "Never trust the client; it is in enemy hands."