Author Topic: Security Sanity Check (Read 7254 times)

Glarawyn · « **on:** November 13, 2007, 06:21:57 pm »

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.

Alreadythere · « **Reply #1 on:** November 13, 2007, 06:41:00 pm »

Your scheme seems fairly save.

I just don't see any problem with repeated information. Either you send the whole online list each time, then any repeat doesn't matter as the best anyone can do is get the list updated for nothing once. Or you only send the logons and logoffs in the last couple of minutes, but as it's either online or offline only there isn't any problem with duplicate information either.

You could add a simple length field, though and truncated coded string should result in a serious mess I think.

Tichy · « **Reply #2 on:** November 14, 2007, 12:15:55 pm »

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.

Glarawyn · « **Reply #3 on:** November 14, 2007, 09:01:24 pm »

- Counter: That's one reason I threw the timestamp in there. If the user doesn't perserve the database or something and the counter starts over the system would outright fail. Using the timestamp for the counter preserves the counter...as long as the system's clock is set properly.

It also makes sure outdated information isn't being posted.

- HMAC: I'm honestly not following you here. This is setup as symmetric key encryption, not asymmetric public/private key encryption. The key is used to both encrypt and decrypt data. Both parties need to know the key, so the key has to be communicated in a secure manner before this will even work.

If you are in possession of the private key, you can decrypt the data, modify the data, generate a HMAC, encrypt and send it on, so the HMAC doesn't do anything useful in this scenario.

So the private key that also authenticates the data. If your private key is compromised, security is broken and the only thing you can do is generate a new private key and use a secure method to make both ends aware of the private key...

If I totally missed something along the way let me know.

Tichy · « **Reply #4 on:** November 14, 2007, 09:16:25 pm »

Quote from: Glarawyn on November 14, 2007, 09:01:24 pm

- Counter: That's one reason I threw the timestamp in there.

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

Quote

- HMAC: I'm honestly not following you here. This is setup as symmetric key encryption, not asymmetric public/private key encryption. The key is used to both encrypt and decrypt data. Both parties need to know the key, so the key has to be communicated in a secure manner before this will even work.

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.

Glarawyn · « **Reply #5 on:** November 14, 2007, 09:54:01 pm »

OK I see it now, sometimes it takes actualy doing it wrong and intentionally breaking stuff to see it.

I setup a quick test implementation. Flipped a couple bits of the cypher text and got a most of decrypted message with gibberish caused by the changed cypher text. Automated process probably aren't going to notice the bad cypher text, but when you have gobbly gook in the middle of what was supposed to be a sentence (or character name) a human reader will notice.

So now I'm following you and yes you are right. I'm still working on my understanding of crypto which is why I posed this in the first place.

I haven't turned this up yet in my google searches, so maybe you know. Is the best practice to put the HMAC in the encrypted data or separate from the encrypted data?

I don't see any issues parsing it out either way, and the HMAC is a one way hash so passing it outside of the encrypted data shouldn't be a security issue. When encrypting binary files it seems like the HMAC should be separated from the encrypted files for simplicity, but you could also include the HMAC as an encrypted file. I'm not dealing with binary files so I'm not going to wrap my head around that today.

With encrypted strings the HMAC doesn't do you any good without the decrypted text, so there is no harm in shoving it in with the rest of the encrypted string as long as you know how to parse out the decrypted string, and in the end I think this makes dealing with and parsing the encrypted and decrypted data easier.

Thanks for helping me find my way to the right way of doing things.

Tichy · « **Reply #6 on:** November 15, 2007, 09:53:25 am »

Quote from: Glarawyn on November 14, 2007, 09:54:01 pm

I haven't turned this up yet in my google searches, so maybe you know. Is the best practice to put the HMAC in the encrypted data or separate from the encrypted data?

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