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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
