41 lines
1.9 KiB
Plaintext
41 lines
1.9 KiB
Plaintext
|
Nodes are expected to send data over the open internet.
|
||
|
|
Therefore we want some kind of authentication to avoid one node
|
||
|
|
impersonating another.
|
||
|
|
Basic auth would be a possibility
|
||
|
|
As would be SSL client auth
|
||
|
|
I'm somewhat leaning towards a simple hash based shared secret scheme,
|
||
|
|
although I'm not entirely sure why I prefer that over basic auth. Maybe:
|
||
|
|
* can be easily implemented in the backend
|
||
|
|
* allows overlapping keys, simplifyig key changes without potential for
|
||
|
|
data loss.
|
||
|
|
Anyway:
|
||
|
|
* Each node has an id
|
||
|
|
* Each node has a secret key
|
||
|
|
* The server also has a list of secret keys for each node
|
||
|
|
* The node includes "auth": {"node": node, "timestamp": timestamp,
|
||
|
|
"hmac": HMAC(key, node || timeetamp) } with every update
|
||
|
|
The server checks against all stored keys for node.
|
||
|
|
If there is no match fail
|
||
|
|
If the timestamp is <= the last recorded timestamp, fail.
|
||
|
|
(this prevents replay attacks but allows for some clock drift)
|
||
|
|
|
||
|
|
Use JWT instead of HMAC?
|
||
|
|
|
||
|
|
+ Public Key instead of shared secret possible (but that only helps if
|
||
|
|
the client signs the request, but then we need either a CA or
|
||
|
|
collect all public keys)
|
||
|
|
- If used as a token, there is no replay protection.
|
||
|
|
- Expiry time has to be set when creating a token.
|
||
|
|
|
||
|
|
Doesn't seem compelling
|
||
|
|
|
||
|
|
Timestamps: I think timestamps are problematic as a replay attack preventer.
|
||
|
|
While for a single process it is easy to ensure they are monotonically
|
||
|
|
increasing, for multiple processes this is not the case. Think of multiple
|
||
|
|
processes started by cron. They will be started almost simultaneously and - if
|
||
|
|
they are simple - also report their findings almost simultaneously. It is very
|
||
|
|
possible that process A gets its timestamp before process B, but B completes
|
||
|
|
its POST request first, invalidating A's timestamp. One possibility would be
|
||
|
|
that A then simply retries with a new timestamp. Another that the server stores
|
||
|
|
timestamps for some time and rejects only timestamps which are older than that.
|