tags:

views:

67

answers:

4

Here's the story:

I have to pass some classified information from one script to another script. In the first script I need to encrypt the data first and then I HAVE TO attach the encrypted data into a GET request and send it to another script, the url would look like this :

http://mydomain.com/mysecondscript.php?secret={encrypted stuff}

My current encrypt method is based on base64, the problem with this method is that if I have a lot of stuff to encrypt, the encrypted result could get very long, if it's longer than 255 characters or so, the second script will not be able to decrypt it because the string will be chopped.

So I'm looking for a better encrpt method that can control the length of the encrypted result.

Any ideas?

A: 

Why does it have to be transmitted in the URL at all? Save it to disk, put it in the database, add it to a message passing queue...

You can use an opaque token in the URL to identify which thing you're talking about, and then turn that token back into a useful thing on the other end by querying whatever storage mechanism you choose.

Aaron Gallagher
@Aaron: Yes, that would be an work around. I need to actually work this out with a GET request.
Shawn
@Shawn: Any chance you can use POST instead? I've passed some decent-length parameters in POST before, so it might work (I don't know if there's a definite difference in max size). GET and POST are similar enough that it might be easy to switch.
peachykeen
@Shawn, exposing this to the user is just asking for trouble. If you have the capability to store this information only on the backend, *please* do so. It'll make your life much easier in the long term.
Aaron Gallagher
A: 

If this is sensitive information, base64 should not be used as it can be decoded easily. If you want the information to be securely encrypted, you shoule use PHP Mcrypt (link). Much more secure and can support encryption of much longer strings. Best of all, you set your own key and it cannot be decrypted without that key. It make require a tiny bit more work, but it will be safe. Also, if you are passing multiple variables that way, you can set them into an array, serialize and encrypt the array, pass the array via GET, and then decrypt/unserialize. It's as simple as that. One last thing, there are also some classes out there that will make Mcrypt a lot easier to use. May want to google to find one, it will make your life easier.

BigRossLabs
+1  A: 

No matter how secure your encryption scheme is you will still need to base64 or URL-encode the result which, you have discovered, will likely exceed 255 characters. The best you can do is compress the data, then encrypt it, then encode it. It will still probably fail. You need to find an alternative to GET.

GregS
+4  A: 

DANGER!

Base64 is NOT a form of encryption, but encoding. Base64 encoded strings are easy to recognize and trivial to decode. Base64 is used to encode data so they can be safely transmitted across non-binary safe medium (such as URLs and emails), but they do not hide the data itself.

What you need to do is encrypt the string using AES (see PHP's mcrypt), then base64 encode it. This of course will not solve your length problem. The question is pretty vague, but what you can do is:

  • Use POST instead of GET.
  • Store data in a database or a file which both scripts can access. Then just generate a sort of identifier and send it with the URL. The receiving script can use this identifier to retrieve the data. As an added bonus you won't have to send classified data with the URL.

EDIT: Now that I read your question more carefully, it seems like both scripts are sitting on the same server. In this case there is no reason whatsoever to pass this data via HTTP.

NullUserException