«

Martin Christiansen wrote:
>
> Because of that, we've decided to provide a "public" interface to our
> database for them to use. We consider the following two possibilities (both
> of which may be relevant):
>
> 1. A public XML Web Service for online-reporting of measurement results
>
> 2. An automated reception of e-mails with attached measurement results (as
> XML-files) for offline-reporting.

3. HTTP URL Encoded forms.

4. Email with one item of data per line.

> However, it should not be possible for just everyone to send data to our
> server - an "evil" person would then be able to ruin the database by
> flooding it with fake data.

Is there a risk of interception? If not just require them to include a
unique combined user ID and password (just has to be non-guessable).

If there is a risk of interception, make sure that either replayed data
is harmless, or that there is a serial number or timestamp in the data,
then add a signed, cryptographic checksum.

At its simplest, that means combining a secret random bit string with
the message, and then using md5 or sha1 to get a check code. Tools for
generating md5 and sha1 can be found in openssl, and there is also a
freeware program called md5sum. There are some theoretical weaknesses
in MD5, which mean that it doesn't give you as much protection as you
might expect from the length of the checksum, and similar may be found
in SHA1, so, if the incentive to forge is high enough, you might want to
combine them, or investigate other choices.

With these simple approaches, you need to communicate the secret bit
string in one way or the other. The simplest approach to that is to
require an initial, paper based registration. The fact that you are
asking at all suggests that you and/or your data contributors do not
understand https well enough to be sure of operating in a way that is
safe from man in the middle attacks.

Alternatively, you can do what https does with its message integrity
checks, and encrypt the checksum with the private key of a public
private key pair, and have the contributors submit their public key to
you, or possibly easier, include the public key in the message as well.

You could, of course, use https, with client authentication, which does
a lot of the hard work for you. (As commonly used, https only uses
server authentication and most end users don't understand how to ensure
that even this is effective.)

With all these, except where you've first gone through a satisfactory
registration process, which involves both sides getting the secret, or
your getting the public key, you need to tag the stored data with the
source, and have the ability to purge all data from that source. Those
capabilities are probably desirable, even with registration.

If interception is considered a risk, you ought to be doing some of this
for your existing data collection devices, as well.

>
>
>
> Question: How can we make sure, that only people we trust can add data to
> our database - dispite that the method for doing so becomes public knowlege?

There needs to be a secret key, as well as the public procedure.