Question

I am developing a web application that will redirect users to an outside web application. I would like to encrypt the redirect url so the users can not directly modify the url. The outside vendor would like to use triple DES. Here is my questions:

1. I assume that the developers of the outside web application and I will have to exchange some sort of “Secret key” so we can decrypt and encrypt the url, is that a correct?

2. Is this “Secret Key” some sort of file or some sequence of characters we can perhaps initially exchange via email?

3. Does it matter that I am writing my web app in Java and the outside vendor is writing their web app in .NET?

Answer 1

Sounds like you need to sign the request parameters, rather than encrypt them. You could try something like this;

1) Create a string of the data you want to protect with a digital signature, for example if your URL is;

http://www.example.com/doCourse?userid=123&courseid=abc

and you want to protect the userid and courseid parameters you create a string;

courseid=abc&userid=123

Note that in cases such as these it is normal to create the string with the parameters in alphabetical order.

2) Use a Message Authentication Code with a cryptographic hash function such as SHA-1 to generate a hash of your string.

Do this with;

Key key = ..... //You need to agree a key with the other party.
String string = ..... //The data you want to sign eg "courseid=abc&userid=123"
Mac mac = Mac.getInstance("HMAC-SHA1");
mac.init(key);
byte[] result = mac.doFinal(string.getBytes("UTF-8");

The MAC basically uses a secret key (which you agree with the other party in advance) to generate a hash of the data.

3) Base64 encode, then URLEncode the result and include it on the redirect as a parameter (call it something like ‘signature’).

4) The other party performs the same actions as you, they generate the string, use a MAC to create a hash, base64 encode and URL encode. Next, they compare the signature on the request with the one they have generated. If it is the same then the parameters have not been tampered with. If the hash is different then the user must have modified them.

You may want to also include a cryptographic nonce with the request to prevent replay attacks. If you use a nonce, make sure you include the nonce parameter and value in the string you use to generate the signature (ensures the user can’t tamper with the nonce).

Advantages over encryption

• URLs are not obscufated at the expense of supporting this in the web apps.
• Security can be achieved with a simple filter in front of the web app that just checks signatures.
• You can tell whether the user has modified the data, which cannot be guaranteed just by encryption. With TDES the user may alter the ciphertext and accidently create a valid but different plaintext.