please tell me why this is stupid

Richard Gaskin ambassador at
Fri Sep 2 12:33:55 EDT 2011

Andre Garzia wrote:
> For the arbitrary data, use some shared secret between both instances, this
> way, someone in the middle can't fake the requests by simply knowing the IPs
> and the milliseconds...

Just to clarify, they not only need to know the IP and milliseconds, but 
must also spoof the IP and be within a certain time limit.

But as for the shared secret, that's the "arbitrary data" I mentioned 

Anything else?

My instincts say this is too simple to be useful, but my desire to have 
it done is tempting me to write it anyway. ;)

  Richard Gaskin
  Fourth World
  LiveCode training and consulting:
  Webzine for LiveCode developers:
  LiveCode Journal blog:

> On Fri, Sep 2, 2011 at 12:33 PM, Richard Gaskin
> <ambassador at>wrote:
>> I need a lightweight embeddable solution for encrypting socket traffic
>> between two LiveCode-based apps.  This is peer-to-peer, so there is no other
>> software involved (no Apache or anything else), just two apps each with an
>> Internet connection, which may be anywhere in the world.
>> For the purposes of this discussion, let's assume that this encryption
>> needs to be super-easy for users to set up, so a standard SSL certificate
>> may not be ideal.
>> And since the communication is only between two apps I would write in
>> LiveCode, we don't need the interoperability advantages of using a standard
>> anyway, so I'm free to explore anything I like, such as the following:
>> The weakest point in client-server communications is sending the
>> authentication data (user name and password).  With FTP and Basic HTTP
>> authentication, for example, those are sent as clear text, exposing the
>> system to anyone intercepting the login traffic.
>> So it occurs to me that before the authentication data is sent, the first
>> request to the server app could be to ask for a token.  This token would be
>> a hash (probably SHA1) of the client app's IP address, the time in
>> millisecs, and other arbitrary data.
>> This token is sent back to the client, which then uses it as the encryption
>> key for the authentication data, and after authentication it continues to
>> use the token to encrypt all other data sent during the session.
>> Any attempt to send data encrypted with the token from another IP address
>> would be rejected by the server since it doesn't match the IP address used
>> to create the token.
>> Similarly, any attempt to use that token in another session would also fail
>> since the time stamp would no longer be within the time limit for the
>> session.
>> And of course once the data itself it accepted, the user name and password
>> would need to match the server's list of known users to do anything further,
>> now less likely since they were never sent as clear text.
>> For a reasonable level of security, this would seem at first glance to
>> solve the problem.
>> The upside to this approach is that it's dirt-simple to implement.
>> The downside is that it's dirt-simple to implement, so my instincts tell me
>> there's likely something obviously wrong with it that I'm just not seeing at
>> the moment.
>> So please help me out:  why is this a stupid idea?
>> TIA -

More information about the Use-livecode mailing list