please tell me why this is stupid

[Richard Gaskin]

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 
earlier.

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: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

>
> On Fri, Sep 2, 2011 at 12:33 PM, Richard Gaskin
> <ambassador at fourthworld.com>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 -