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 encryption method, that can control the length of the encrypted result.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
Shawn
  • 32,509
  • 17
  • 45
  • 74
  • 2
    Is it possible for you to use a POST request, which will not be inhibited by the annoying ~255 char limit? – karim79 Aug 13 '10 at 03:32
  • AFAIK GETs are limitted to the URL size, which is browser-dependent. IE supports URLs of up to 2,048 bytes, other browsers have much, [much bigger limits](http://www.boutell.com/newfaq/misc/urllength.html). – NullUserException Aug 13 '10 at 14:30
  • related answer with a complete solution: http://stackoverflow.com/questions/9465369/a-good-practice-for-creating-human-typable-non-sequential-unique-ids/9466640#9466640 – Kaii May 08 '13 at 09:52

5 Answers5

16

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.

Community
  • 1
  • 1
NullUserException
  • 83,810
  • 28
  • 209
  • 234
  • "*In this case there is no reason whatsoever to pass this data via HTTP*" .. Why do you think there is no reason to pass this data via HTTP, then what you are proposing?? Could you please clarify, do you mean storing database or in a file and then both applications retrieving from there ?? I see an additional network call in this case .. – hagrawal7777 Feb 09 '16 at 11:47
  • @hagrawal If both scripts are running on the same server, there is no reason for you to send sensitive data using HTTP – NullUserException Feb 23 '16 at 21:36
  • That's what is the question, why? And what is the alternate you are proposing? – hagrawal7777 Feb 23 '16 at 21:52
  • If both scripts are on the same server all you have to do is have one script tell the other *where* to find that data (but not the data itself). You can have that data in a file or a database; it doesn't matter. All one script has to tell the other is some sort of ID (for example, the primary key in a database) and the second script can find it based on that ID. Yes, something still goes through the network, but no sensitive data is exposed to the outside world. – NullUserException Feb 24 '16 at 00:38
2

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.

President James K. Polk
  • 40,516
  • 21
  • 95
  • 125
0

You can use MD5 to create a hash of the id so you get something like:

http://www.demo.com/displaycommittees.php?id=81dc9bdb52d04dc20036dbd8313ed055

In your db query you can do a select on the users table including a WHERE statement that also hashes the id column like:

WHERE MD5(id) = $_GET[id]

This works fine and i have always applied this algorithm. for instance assuming the actual value of the encrypted id 23, if you try to put 23 in place of the encrypted(hash) code it will not work( no result will be display).

Note: Reasons are best known to those who need a solution, so the question "why" may not come in for those who need it. they only ask for a solution and if it works fine for them, nice. But for transaction application (e.g cash transaction or transaction pins) please do avoid passing sensitive information via URL, because it can easily be cracked.

Okwo moses
  • 85
  • 6
0

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.

habnabit
  • 9,906
  • 3
  • 32
  • 26
  • Yes, that would be an work around. I need to actually work this out with a GET request. – Shawn Aug 13 '10 at 03:23
  • @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. – ssube Aug 13 '10 at 03:33
  • 1
    @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. – habnabit Aug 13 '10 at 03:34
0

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.

Kyle Ross
  • 2,090
  • 4
  • 20
  • 27