please tell me why this is stupid

[Bob Sneidar]

What happens when you change the internet provider on either end? You need a mechanism for re-establishing the link. 

Bob


On Sep 2, 2011, at 9:33 AM, Richard Gaskin wrote:

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