Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=hXBQ6bMQQ1Gzd0DTzIsnDrgR7njOemJeL/zMrsvzzJ7LC3kh4HbpT+pJXPhnCQiFej g3fa1F3r821lsQ+Mqg/ZQQ98VmqQkp2sEOnPQhiazx+V3KpDlf5vSSRBN/UQ36BAqtlf 3Oq9jOpytpB9w+f6wRBJnhDiqnmLfpVCEG790=
MIME-Version: 1.0
In-Reply-To: <BANLkTi=fU9p3b_JQK_jtAf3NYhcbzFoOcA@mail.gmail.com>
References: <d8c7dc52-0c54-4b29-a7b6-bcd833686611@q12g2000prb.googlegroups.com> <BANLkTim5phU5X0CXhCNsY75OjqDCLvkXtg@mail.gmail.com> <BANLkTi=fU9p3b_JQK_jtAf3NYhcbzFoOcA@mail.gmail.com>
Date: Sun, 19 Jun 2011 09:12:13 +1000
Subject: Re: Strategy to Verify Python Program is POST'ing to a web server.
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.132.1308438742.1164.python-list@python.org>
Lines: 42
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:7929

On Sun, Jun 19, 2011 at 6:40 AM, Michael Hrivnak <mhrivnak@hrivnak.org> wro=
te:
> On Sat, Jun 18, 2011 at 1:26 PM, Chris Angelico <rosuav@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. =A0When 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. =A0Yikes!

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