So I have a web page that displays who's online. (See http://www.sentinels.us). The web server and bot server are on separate computers.

The original web page was written by Beaker. To update the online list on the web page you load a special URL. PHP script takes in the parameters, updates the URL. In Beaker's version, access to the update script is limited to IP address. I want to improve that a bit...

My through was to use PHP's mcrypt functions and generate a security key. For example, the Bot and the web page would have a preshared encryption key and a pass phrase.

My idea for authentication is when the bot needs to update the webpage, it would take the passphrase, current UTC timestamp, and online users, encrypt that information with the shared key, and send that to the web server. If the web server can decrypt the string, the passphrase matches, and the timestamp is within tolerance (5 minutes) the web server's online list would update. Otherwise updates would be rejected.

Anyone sniffing the wire could replay the URL, but as all the information was encrypted replaying the encrypted string will only produce the same results as the bot produces, and that URL is only valid for a limited time.

Currently the bot module can only send updates to the web server once per minute, and it will only send an update if something has changed.

I know that this should work and should be reasonably secure for the application when using the right encryption...but what can be done to eliminate the possiblity of replay?

Track the most recent accepted time stamp I suppose...the next time stamp has to be greater than the previous.

Any suggestions or better methods would be appreciated.

To prevent replay attacks, just add a counter to the bot. Whenever the bot sends an online update, it adds the counter value to the update and increments the counter.

The receiving script records the last received counter value and only accepts updates with higher counter values (if there is an update lost, this is no problem since the most recent update has the highest counter value and is accepted).

Of course the counter value in the updates must be secured by some hashing function against alteration.


Your scheme ist not save :

You wrote you do some encryption on the updates... this is no authorization nor did it guarantee any consistency. So you need to add a HMAC for consistency, the encryption only guarantees confidentiality.

You did talk from a time window... this gives a replay window. And the clocks have to be syncronized. Counters sounds more robust to me



Encryption gives only confidentiality. Someone could record your message, change some bits and send it again, you would'n notice about that. But if you add a HMAC, you could check for integrity of the message. (H)MAC is needed to give you integrity and authenticity... this is for symetric encryption.

I think the common way is to authenticate the encrypted message. If the message was changed by an attacker, you will detect it at the very beginning an discard the message (more robust against DoS attacks). If the keys are secret, this gives the advantage to only decrypt authenticated messages (so it is more difficult i.e. to use buffer overflows in the decryption part). But I'm not a crypto expert