please tell me why this is stupid

[Richard Gaskin]

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 -

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