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