please tell me why this is stupid

[Andre Garzia]

Richard,

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

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 -
>
> --
>  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<http://LiveCodejournal.com/blog.irv>
>
> ______________________________**_________________
> 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<http://lists.runrev.com/mailman/listinfo/use-livecode>
>



-- 
http://www.andregarzia.com All We Do Is Code.