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