Hello Paul,

IMHO

If you were programming a real time internet chess application, you would need to send moves (hopefully through an encrypted request) and track/validate/authenticate origin, for everything at the server, or cheating would be very easy; however, if you have a game that relies on the client to monitor progress and report it, encrypted intermittent requests, even though they still leave wide open wholes on the client layer, will have to be enough.

Good luck,
Anthony Pace

Ron Wheeler wrote:
Paul Steven wrote:
Thanks Ron - that is another great idea. So I guess I could send a message after each level with the time elapsed and score at this point - then check
at the end if all level messages have been received.
And that sufficient time has elapsed.
I think my clients main concern with regards hacking was related to hackers being able to inject malicious code via my PHP/MYSQL code which could affect
other elements on their server apart from the game.

A good audit by a security consultant or independent PHP expert might help. They could also use and http proxy (Apache mod_proxy) and put your application on its own server or virtual server with its own MySQL for added security.

Ron
Cheers

Paul

-----Original Message-----
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ron Wheeler
Sent: 23 April 2009 21:02
To: Flash Coders List
Subject: Re: [Flashcoders] Feasibility of xml file for high score data
storage

One of the possible tricks that you can use, is to send messages to your "high-score" server during the game so that you can verify that the person passed certain checkpoints. You can throw these away after the final score is recorded and validated. At the checkpoints, you can record current score, a game state(if that is relevant) and a timestamp and then do a quick reasonableness check when the final score is recorded.

You need to assume that the cheater has read your client-side code.
A determined cheater can always build a simulator for your game and replace your game with their simulator.

The crossdomain file gives you some protection.

Ron


Paul Steven wrote:
Thanks jonathan - that is very useful to know. I am now going to
incorporate
some security anyway as the client wants it to be "hacker-proof" :)

-----Original Message-----
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of jonathan
howe
Sent: 23 April 2009 15:10
To: Flash Coders List
Subject: Re: [Flashcoders] Feasibility of xml file for high score data
storage

I've done several games with relatively open high score systems. There was
no prize for winning, and people cheated within the first 2 hours of
launch.
Don't assume they wont! Especially if the score chart posts usernames.

On Thu, Apr 23, 2009 at 4:38 AM, Paul Steven
<paul_ste...@btinternet.com>wrote:

Ah I see - thanks Glen.

For this particular project, there would be very little benefit in
cheating
as there is no prize. However it certainly sounds like something I will
use
on my other game projects.

Thanks for your time writing out the explanation.

Cheers

Paul

-----Original Message-----
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Glen Pike
 Sent: 22 April 2009 15:27
To: Flash Coders List
Subject: Re: [Flashcoders] Feasibility of xml file for high score data
storage

Hi,

   The public / private key thing is just about "encrypting" some of
the score data that you pass to the server to stop people cheating your
high score tables.

   for example, if your high score system in PHP uses a GET / POST
something like this:

   scores.php?name=Glen&score=500

   It's easy for me to cheat...

   But if you do (pseudo code):

   var key:String = "mysecretkey";

var encrypted:String = MyEncryptClass.encrypt("name=Glen&score=500",
key);

   var result:Boolean = MyServer.sendScore(encrypted);

   And it does something like this:

   scores.php?command=submit&encrypted=asdiou23q890czoued9auc0

   You can then use the server key to decrypt your message.

   (Public & Private keys are about "asymmetrical" encryption)

   Anyway, the idea is to make it harder for people to cheat - as the
"data" is not very sensitive, you can go for a simple encryption option
where you store the key in the SWF, which means that people can still
decompile your Flash file and find out the key, but only the most
dedicated of cheaters would do that...

   If you really want to go to town, you are probably going to have to
create some kind of "login" for people to play the game / submit high
scores, but to be honest, you can just go for simple score encryption -
look at Jobe's stuff again - if your game does not have any kind of
prize...


You can get some AS3 / AS2 code that handles encryption which can be
decrypted with functions in PHP. I have some links at home I can post
later if you like..

   Glen

Paul Steven wrote:
Thanks for the reply Anthony.

Can you elaborate on the public private key system and what this
entails?
I
have not heard that term before.

Thanks

Paul

-----Original Message-----
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Anthony
Pace
Sent: 22 April 2009 14:25
To: Flash Coders List
Subject: Re: [Flashcoders] Feasibility of xml file for high score data
storage

Hello Paul,

Making good use of a que would be required for writing to the file
without errors, so a database is the best and easiest way; as well, for
high scores, you might want to use a public private key system for
preventing xss exploits, as anyone that knows how to intercept and edit
the get or post data will be able to screw with the request to the
server, and you could end up with a hundred people having the best score
that the column in the DB will allow.

Take care,
Anthony

Glen Pike wrote:

Not working for Cornwall County Council by any chance??? :)

Paul Steven wrote:

Thanks Glen and Ian

Yes I am currently using a mysql database while the high scores are
hosted
on my site. The game is for a rather large organisation so it is not
the
easiest task in the world getting a database set up at their end. The
mention of flash alone was enough to cause major panic so you can
imagine
the fear when I mentioned the need to upload php files to their
server:)
Cheers

Paul

-----Original Message-----
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Glen
Pike
Sent: 22 April 2009 12:15
To: Flash Coders List
Subject: Re: [Flashcoders] Feasibility of xml file for high score data
storage

I am guessing that any server side code to update the XML file will
rely on the server to "lock" files, etc.
Databases are often optimised to allow for multiple "clients" to
update, but most file based commands will lock the file preventing
access by other "clients" so if your code throws a wobbly rather than
waiting, that could be a problem...

Saying that, you could look at using SQLLite for example - this uses
a file based database, but your SQLLite "engine" will handle all of
the access - a lot of PHP installations come with this nowadays and
ASP code also uses ADOBC to connect to Access database files so you
will have a similar system.

The upshot is that using a server side database engine will make life
easier because they will deal with problems like concurrent
connections for you :)

Glen

Paul Steven wrote:


I was considering using an xml file to store high score data for a
game.


It


is quite possible that this game will have a significant amount of
traffic
(certainly in the first few days after launch) and I am now
wondering if


an


xml file would be suitable. I am not sure what happens in the
scenario
where


multiple players want to update the highscore at the same time -
they will
all need to write to the file. I assume this is the same scenario
with a
database but think perhaps updating a database is more efficient.

Anyone care to offer any insight into whether an xml file would be


suitable


or not?
Thanks

Paul

_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders




_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders




_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders



_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders



_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders



_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Reply via email to