please tell me why this is stupid

Bob Sneidar bobs at twft.com
Fri Sep 2 11:54:07 CDT 2011


If both ends support OpenSSH then can't you simply get the public key for the machine the first time you connect and store that? But then of course, a wipe and reinstall of the OS hoses that. Apple computers natively support it, but Windows XP does not. (Not sure if Vista or Win7 have caught up yet). 

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




More information about the use-livecode mailing list