[mtasc] using server side mtasc for security
Benjamin C. Allfree
benles at bldigital.com
Wed Aug 17 19:37:50 CEST 2005
It sure seems easier to dole out tokens that expire in 5 minutes.
The fundamental problem of verifying a client's authenticity can not be
solved in your situation. You need a private key that is known only by the
client and the server, and a secure data channel. You have a secure channel,
but since you must transmit the key to the client before you will both have
it, anyone can get it. Furthermore, the private key stored on the client can
This is why DVD players got hacked..
> -----Original Message-----
> From: mtasc-bounces at lists.motion-twin.com [mailto:mtasc-
> bounces at lists.motion-twin.com] On Behalf Of hank williams
> Sent: Wednesday, August 17, 2005 9:48 AM
> To: MotionTwin ActionScript2 Compiler List
> Subject: Re: [mtasc] using server side mtasc for security
> Not really.
> What I am suggesting is that by generating the client on the fly where
> the client knows how to do something that the server needs to see, and
> where the server expects to see that pattern of behavior from that
> client for only a limited time window, that you can gain a higher,
> although not perfect level of trust. Imagine if you create a new
> language every 5 minutes and only the clients that have been created
> in the last five minutes know how to speak it and the server is
> expecting to hear this new language, then hacking can be made to be
> much harder. The more complicated you make the language, and the
> shorter you make the time window, mathematically, the closer this
> comes to being a form of client encryption.
> On 8/17/05, Timo Stamm <t.stamm at macnews.de> wrote:
> > hank williams wrote:
> > > I have been thinking about the problem of how to secure remoting
> > > applications in flash.
> > >
> > > The problem is that it is generally easy (or at least not impossible)
> > > to make a remoting server believe that a fake flash client is actually
> > > a legit flash client.
> > You can not trust the client, therefore there is definitely no way to
> > secure the connection.
> > What you suggest is obfuscation.
> > Timo
> > --
> > MTASC : no more coffee break while compiling
> MTASC : no more coffee break while compiling
More information about the mtasc