Guard against replay attacks

[jaythomas]

Say a hooligan wants to send garbage measurements to an api server. If they knew the both the ID and private key of a station they could easily do so. To prevent this, the key is never sent as part of the datagram. Simply a hash derived from the key is used.

And that's it. There is no handshake or further encryption of the message. The weather station sends the UDP datagram and goes back to sleep as quickly as possible. It doesn't wait around and waste battery life.

What this means for the hooligan is if they don't have an id and key of a weather station, if they intercepted a datagram they would have a valid message they could send and re-send to the server over and over again to fill up the database with bogus measurements. This is a replay attack. This scenario isn't likely so I'm not labeling the issue as a critical vulnerability or anything like that. But it may be possible to fix while maintaining compatibility with the current message specification.

Let's say every message send from a weather station has a randomly-generated UUID included in it:

air_temp=23.4,humidity=62.45,id=053050d3-7fa7-438d-93f1-8285fd5eef79,uuid=469f1b70-712a-4cb6-9a87-da8eff3e90ba
#540151989

Since the hash changes every time the message changes, no two messages will have the same hash assuming each uuid is indeed unique. The api server can store this uuid in a new column (or part of the measurements' ID's in some way) and look up later when adding new measurements to make sure it hasn't seen this uuid before.