Hi Nick, thanks for this. I've added it to our presentation archive:
http://www.nyphp.org/content/presentations/
Quick reminder for the Jan meeting: you'll need to RSVP *AFTER* Christmas
Day - I'll send out a reminder.
To all NYPHPers, have a healthy and a happy. 2008 is going to be another
e
I wrote a couple flash client / php server casino games. I didn't
actually do the flash client part (takes me forever to produce nice
looking stuff with that app) but I did come up with the api. It used
a token and timestamps that were hashed with a secret key - pretty
similar to the way
Thanks to all for the help. Since there are no cash prizes and this
is part of online educational software that requires a subscription, I
doubt anyone will care enough to decompile the swf. I did check the
database however, and it appears there are 2 university students that
are resending the re
On Dec 12, 2007 12:51 PM, John Campbell <[EMAIL PROTECTED]> wrote:
> I don't follow how this is any better than what I have now? The
> public key is still stored in the swf, and there is nothing that
> prevents the key from being extracted from the swf and the request can
> still be forged. This
Due to the nature of Flashs, someone will always be able to revere
engineer the code.
So how about this(if it doesn't slow things down too much):
When the game loads up, have the Flash program connect to the server and
provide it with some information(how about hashing the ipaddress,
username,
csnyder wrote:
> On Dec 12, 2007 10:32 AM, John Campbell <[EMAIL PROTECTED]> wrote:
>
>> Initially the scores were send as a simple post request, e.g.
>> name=john&score=1000. This is a problem because it is trivial to
>> forge the request. So my solution was to create the post request as
>> fol
Hi yah,
re: Chris and public/private key pairs.
In your solution/example, anyone with the public key can talk to the server.
Since anyone with the public key can then forge messages somehow you have
to "hide" the public key. This isn't any different from use plain old
secret keys as he did
> Yes there is, John, but you may need to seriously consider whether
> implementation is worth it.
>
> You can use a public/private key pair to perform asymmetric
> encryption. That means that a value encrypted using one key can only
> be decrypted using the other. This is the encryption scheme use
Aha! Good point.
So there are a few ways you can do this. But i think the simplest is just
to record the username (perhaps the ip), and highscore and time stamp. Then
when a new message comes in check the db to see if this user's timestamp is
close to now. If so, reject.
More complicated ways
On Dec 12, 2007 10:32 AM, John Campbell <[EMAIL PROTECTED]> wrote:
> Initially the scores were send as a simple post request, e.g.
> name=john&score=1000. This is a problem because it is trivial to
> forge the request. So my solution was to create the post request as
> follows:
>
> name=john&sco
Thanks Nick,
I'll take some measures to obfuscate the "secret", but I just realized
I have another potential hole. There is nothing to prevent someone
from actually getting a high score, then replaying the request to get
all of the top positions. I suppose the solution is to have the
server crea
Hi John,
Great question.
Your general idea is sound, but sadly there is no such thing as a "secure
client". If there were, every game client (unreal, wow, etc), IM client,
dvd player, cable tv box, xbox, iphone, etc would use it. But these are
routinely cracked.
The only thing they do differen
Thanks for the presentation.
I have a question that is related, but along different lines. I have
a flash game that saves high scores to the server and I want to
prevent high scores from being forged.
Initially the scores were send as a simple post request, e.g.
name=john&score=1000. This is a
At 5:13 PM -0500 12/11/07, Nick Galbreath wrote:
Hello,
First thanks everyone for coming out the NYPHP on 27-nov-2007 for my
talk on "Tamperproof URLs and PHP"
Based on your feedback, comments, and uhhh, a few blank stares, I
completely revamped the slides.
Right now, I've dumped the slide
Hello,
First thanks everyone for coming out the NYPHP on 27-nov-2007 for my talk on
"Tamperproof URLs and PHP"
Based on your feedback, comments, and uhhh, a few blank stares, I completely
revamped the slides.
Right now, I've dumped the slides, the source code and the unit test here:
http:/
15 matches
Mail list logo
