I have to answer a question on sending data from one server to another:

 

 

Assume that a form is being generated on an external server and posted to a different server via a server side post. What measures can you take to ensure that the form originated from the correct server and contains data that has not been altered on route by a third party. Assume that the form is always sent in plain text and HTTPS is not available.

 

I assume the crux is some kind of data encryption. If we assume the scripting language is php, could an md5 be used? Any ideas you have on this are appreciated. Regards,

 

Sobredosis

You're told you can't use HTTPS and things like IP access lists can be by-passed by spoofing. Also note you're not being asked for data security (encryption), just integrity (data not modified by man-in-middle). I know how I'd accomplish this, but since this is homework assignment or similar I won't tell you the answer. However, hint: shared secret key. And yes, MD5 or SHA1 could be useful in the toolkit too.

I have practical experience of web development, but don´t know much about cryptography (I know some things about DoS attacks and blocking illegitimate SQL queries, but nothing of inter-server security). The test is part of a pre-interview screening. I saw that MD5 is a one-way encryption, i.e. it can´t be read once encrypted, but that makes it useful for passwords where the encrypted copy can be compared against the encryption of the same value which the user should know (that´s why they can only be re-set and not recovered when you "forgot your password"). So in this case MD5 might not be useful (since the receiving end would have a meaningless encryption).

 

I´m just thinking/typing aloud. Could you explain some other terms? Are "IP Access Lists" another security measure? And what is "spoofing"? Thanks,

In the question I read the data is "posted to a different server via a server side post". So I read that as meaning that your form posts to your server first, and it forwards that data to the foreign server via another background HTTP POST. This has to be the case in order for the second server to verify the authenticity of the data - otherwise you have a client who could (and usually will) be absolutely anybody, and this defeats the point of any integrity checks.

 

So we're passing between server A and server B that are both ours and both under our control.

 

As you said, if you do a hash (MD5 or better SHA1) of the data to be transmitted, you'll just get the same result anybody could produce, and it's useless. But, what if both machines store a shared secret key - like a really strong password we have setup on both machines? Then if we have the DATA and the KEY we could send data in the POST body like this:

 

hash(concat(DATA,KEY))
DATA

So we've concatenated the DATA with the KEY and produced a hash (MD5 or SHA1 or similar) value. We transmit that across to the second server.

 

Now, how could that second server verify the integrity of the DATA it receives? And how can you ensure a man-in-middle attack is made infeasible?

 

 

Are "IP Access Lists" another security measure? And what is "spoofing"?

An IP access list allows or denys access by foreign machines based on their IP address. For example, if server A has IP 192.168.0.20 and server B has IP address 192.168.0.21, then server B might be configured to only accept connections from 192.168.0.20 and block all others. Hence only your server A can connect to server B... that is, unless someone spoofs the IP address 192.168.0.20 on their own machine and pretends to be server A, which isn't too hard to do. Hence IP access lists are one form of security, but aren't secure enough alone to rely upon.

Anyway, thanks for the shared key clue. That should be enough to go on... the other questions are just out of interest.

I just read Connecicut´s post. Am I right in thinking that what you´ve said is enough? In simple terms, Server A and B both have the key and so when server B receives the concatenated version of the data, it can subtract the value of the key from the encryption and will have the original. If anyone else gets the data they won´t know which part is the data and which part is the key?

 

In which case, it is still possible to intercept and manipulate the data, but you could only turn it into rubbish. Server B will find that it can´t be de-encrypted because the key part of the encryption has been interfered with so it has to "ask" for a repeat transmission of the same data.

In simple terms, Server A and B both have the key and so when server B receives the concatenated version of the data, it can subtract the value of the key from the encryption and will have the original.

Not quite. Remember I said Server B receives the hashed concatenation of the data and the key. The hash (MD5 or SHA1) part is important - no good just sending the data with a key tacked on the end because...

 

If anyone else gets the data they won't know which part is the data and which part is the key?

if the key was simply tacked on the end of the message, the key would become very obvious after only two messages had been snooped by an attacker.

 

Example: my key is 123456 and my data is just the word DATA. I want to send the DATA without it being modified en-route. So I get Server A to do this:

 

• Append the key (123456) to end of the DATA to give: DATA123456
  
• Calculate the hash of this concatentation, e.g. MD5(DATA123456) = 70cde2d902105dfbb4e8495c28fbb941
  
• Send the DATA and the hash just calculated to the other server, for example as 70cde2d902105dfbb4e8495c28fbb941 DATA
  

 

Now I have transmitted one hash value (which somewhere contains the shared secret key) and the original DATA.

 

You don't send the key in plaintext, nor do you send a hash of it by itself. Both would be pointless. But a hash of the combined data and the key (simple concatenation suffices) does provide data integrity guarantee. Why? And how can the server at the other end check the integrity of the DATA, since it can't invert the hash function? Think about it.

The packet is sent as

70cde2d902105dfbb4e8495c28fbb941 DATA

So this process doesn't ensure confidentiality of the transmission, simply an assurance that its not been modified. I assume the practice on Server B's side is to take the hash value of DATA + key and check that it matches the hash value sent with the data.

So this process doesn't ensure confidentiality of the transmission, simply an assurance that its not been modified. I assume the practice on Server B's side is to take the hash value of DATA + key and check that it matches the hash value sent with the data.

Yes, that's exactly it.

 

Note the question didn't ask you to provide confidentiality (encryption). It asked you to ensure the message:

 

• originated from the correct server
  
• contains data that has not been altered on route by a third party
  

The pre-shared secret key we used does both of these since we assume it is only known by Server A and Server B. If the hash didn't match, one of the assumptions above would be incorrect.

 

If you wanted confidentiality, you could use a symmetric encryption algorithm using the pre-shared key at each end. This is basically what HTTPS does, except SSL also provides it with the way for Server A to generate a new key each time and send it to Server B without it being discovered.