On Sun, Jun 19, 2011 at 6:40 AM, Michael Hrivnak <mhriv...@hrivnak.org> wrote: > On Sat, Jun 18, 2011 at 1:26 PM, Chris Angelico <ros...@gmail.com> wrote: >> SSL certificates are good, but they can be stolen (very easily if the >> client is open source). Anything algorithmic suffers from the same >> issue. > > This is only true if you distribute your app with one built-in > certificate, which does indeed seem like a bad idea. When you know > your user base though, especially if this is a situation with a small > number of deployments, than you can distribute a unique certificate to > each client, signed by your CA.
That changes it from verifying the program to verifying the user. It's a somewhat different beast, but it still leaves the possibility of snagging the cert and using it in another program. Same with IP address checks. You can't prove that the other end is a particular program. >> You could go a long way toward it, though, by >> using something ridiculously complex, such as: >> ... > > An authentication process that involves the client executing code > supplied by the server opens up one single point of failure (server is > compromised or man-in-the-middle attack is happening) by which > arbitrary code could get executed on the client. Yikes! Yeah, hence the part of verifying the server's cert too. That one is a bit safer though; nobody but you will have that certificate, so it's not as easy to take and put into another program. But this whole scheme was meant from the start to be ridiculous. > If ... > then you'll have to accept that you cannot trust the submitted data > 100%, and just take measures to mitigate abuse. I still stand by my original point, namely that the "if" on here is superfluous, and the "then" is unconditional. But the measures you describe _do_ reduce the likelihood significantly. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
