SitePoint Sponsor

User Tag List

Results 1 to 23 of 23
  1. #1
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    chennai
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Encrypted Data via URL

    Hi All,
    I posted this Thread in PHP forum,but i did not get much reply,so i am posting it here.


    Is there any way to encrypt a value that is passed via url,so that the user doesnot know what the data it is.After that i should be able to decrypt that data and get the necessary info to the user in that php page.

    Any Suggestions?

    Thanks,
    php_kid

  2. #2
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You could use MD5 I suppose, but it depends on what your passing via the URL? This isn't an advanced topic btw

  3. #3
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    MD5 is a one way hash. You can use it to check for integrity, but for encryption & decryption.

    Check your phpinfi, if you have mcrypt enabled, that offers cryptological functions: http://de.php.net/mcrypt . But be aware that the space available in the URL is limited, and you may not be able to pass a lot of information.

    If you don't need encryption, and only want to disguise data, you can use base64.

    Just fo curiosity: Could it be that you are trying to solve the wrong problem? Why do you want to pass information to the user via url, only to get it back again? There may be better ways to achieve your real goal.

  4. #4
    SitePoint Enthusiast
    Join Date
    Mar 2004
    Location
    south
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    encryption

    Here are some classes to help:
    PHPSecureURL [http://www.phpclasses.org/browse/package/1107.html]
    Total URLEncrypt [http://www.phpclasses.org/browse/package/197.html]

    I pass primary keys in the URL and I hide primary keys in hidden fields to post to a page. I encrypt and decrypt the primary keys using the following code, it's very fast and doesn't require anything else installed, but I'm sure it can be broken. It's more to obfuscate than prevent a super hacker from tampering:

    /* -----------------------------------------------
    @Name: Encrypt()
    @Args: $txt-> String to encrypt.
    @Args: $CRYPT_KEY -> String used to generate a encryption key.
    @Returns: $estr -> Encrypted string.
    ----------------------------------------------- */

    function encrypt($txt,$CRYPT_KEY){
    if (!$txt && $txt != "0"){
    return false;
    exit;
    }

    if (!$CRYPT_KEY){
    return false;
    exit;


    }

    $kv = keyvalue($CRYPT_KEY);
    $estr = "";
    $enc = "";

    for ($i=0; $i<strlen($txt); $i++) {
    $e = ord(substr($txt, $i, 1));
    $e = $e + $kv[1];
    $e = $e * $kv[2];
    (double)microtime()*1000000;
    $rstr = chr(rand(65, 90));
    $estr .= "$rstr$e";
    }

    return $estr;
    }

    /* -----------------------------------------------
    @Name: Decrypt()
    @Args: $txt-> String to decrypt.
    @Args: $CRYPT_KEY -> String used to encrypt the string.
    @Returns: $estr -> Decrypted string.
    ----------------------------------------------- */

    function decrypt($txt, $CRYPT_KEY){
    if (!$txt && $txt != "0"){
    return false;
    exit;
    }

    if (!$CRYPT_KEY){
    return false;
    exit;
    }

    $kv = keyvalue($CRYPT_KEY);
    $estr = "";
    $tmp = "";

    for ($i=0; $i<strlen($txt); $i++) {
    if ( ord(substr($txt, $i, 1)) > 64 && ord(substr($txt, $i, 1)) < 91 ) {
    if ($tmp != "") {
    $tmp = $tmp / $kv[2];
    $tmp = $tmp - $kv[1];
    $estr .= chr($tmp);
    $tmp = "";
    }
    } else {
    $tmp .= substr($txt, $i, 1);
    }
    }

    $tmp = $tmp / $kv[2];
    $tmp = $tmp - $kv[1];
    $estr .= chr($tmp);

    return $estr;
    }

    /* -----------------------------------------------
    @Name: keyvalue()
    @Args: $CRYPT_KEY -> String used to generate a encryption key.
    @Returns: $keyvalue -> Array containing 2 encryption keys.
    ----------------------------------------------- */

    function keyvalue($CRYPT_KEY){
    $keyvalue = "";
    $keyvalue[1] = "0";
    $keyvalue[2] = "0";
    for ($i=1; $i<strlen($CRYPT_KEY); $i++) {
    $curchr = ord(substr($CRYPT_KEY, $i, 1));
    $keyvalue[1] = $keyvalue[1] + $curchr;
    $keyvalue[2] = strlen($CRYPT_KEY);
    }
    return $keyvalue;
    }

  5. #5
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just to make the obvious point, but there is nothing secure about passing a string in the URL, encrypted or not - if its decryptable (which you state you want it to be) then ANYBODY can decrypt it.

  6. #6
    SitePoint Enthusiast
    Join Date
    Mar 2004
    Location
    south
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes it could be decrypted but if you are passing primary keys it shouldn't be an issue.

    If they decrypt the key and it is '12' and they want to pass '24' to see what is returned they would have to encrypt the '24' using the same algorithem that your app is expecting for the app to decrypt the key and display the data. If the key is encrypted using some other encryption different then yours your app will not work and they won't be able to see data they aren't suppose to see.

    I don't see how they could get around that issue so it seems secure (unless they know your algorithem - maybe I shouldn't have posted the one is use ;0).

  7. #7
    SitePoint Guru silver trophy Luke Redpath's Avatar
    Join Date
    Mar 2003
    Location
    London
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Surely it wouldn't be difficult to run a string through a list of common decryption algorithms?

  8. #8
    SitePoint Enthusiast
    Join Date
    Mar 2004
    Location
    south
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Figuring out the key and the algorithm you are using would be a significant challenge.

  9. #9
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think you make things very complicated. Also there are too many operations executed. And sometimes time is vital.

    Look at the XOREncode class that I have developed at: http://itdev.remiya.com/index.php?id=0_1_2_3

    And instead of generating random keys, better use the username, made in a hush as a key.

    BTW it is well known that the XOR encryption is the fastest possible.

    Put simplicity first.


  10. #10
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Luke Redpath
    Just to make the obvious point, but there is nothing secure about passing a string in the URL, encrypted or not - if its decryptable (which you state you want it to be) then ANYBODY can decrypt it.
    That's not neccesarily true so long as you encrypt your parameters with a key that is kept on the server side and not available to the end user. This would at least make it very hard to decrypt your string.
    Garcia

  11. #11
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I forgot to mention, that if you use URL to transmit data, keep in mind that using GET is limited.

    I'm not sure for the limit, but as much as I remember it is up to 256 bytes.

    Hope that helps

  12. #12
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dvanatta
    Yes it could be decrypted but if you are passing primary keys it shouldn't be an issue.

    If they decrypt the key and it is '12' and they want to pass '24' to see what is returned they would have to encrypt the '24' using the same algorithem that your app is expecting for the app to decrypt the key and display the data. If the key is encrypted using some other encryption different then yours your app will not work and they won't be able to see data they aren't suppose to see.

    I don't see how they could get around that issue so it seems secure (unless they know your algorithem - maybe I shouldn't have posted the one is use ;0).
    1. Public key encryption just to encrypt a URL? Pretty redundant.
    2. If your keys are 12 and 24, then factoring them will be easy as a snap. You need to use AT LEAST 1024bit keys, and I don't think a URL can quite contain that.

    Why not just use sessions?

  13. #13
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    I'm not sure for the limit, but as much as I remember it is up to 256 bytes.
    A lot more than that. 256 characters would be inadequate for many every day situations. Because this depends on so many factors (browser, server, OS), there isn't a specific number, but most people agree that staying under 1000 characters is a good idea. Note that "characters" and "bytes" aren't exactly equivalent in this context.
    Garcia

  14. #14
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Note that "characters" and "bytes" aren't exactly equivalent in this context.
    True, some characters are 1 byte, whilst others are 2 bytes, dependent on the character encoding if I'm correct? Ie UFT-8 and UTF-16 for example. The general safe cut off point for the number of characters limited to $_GET is generally 256.

    Most browsers will settle with that, whereas if you go over that limit, browser X may just cut off the remainder, but finding a compatible list of browsers, and their exact limits is proving difficult.

  15. #15
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    The general safe cut off point for the number of characters limited to $_GET is generally 256.
    Depends on who you ask, and how many years ago you asked the question
    There might have been an arcane browser ages ago that imposed such limit, but I've never heard of one. A URL that fills up the whole visible portion of my address bar is just under 200 charcaters, and I we all go to websites everyday that fill up at least twice that much. 256 is not only very hard to adhere to, but there is no reason to believe this is the limit unless you are aware of specific browser X which has this limitation. I am not aware of such browser. The most restrictive browser in this regards (Internet Explorer) allows up to 2038 characters. Even the old, decrepit, obsolete, we-no-longer-cater-to, Netscape 4.x has a limit of 30,000 characters.

    http://www.boutell.com/newfaq/misc/urllength.html

    From the makers of the very popular GD library (not that it has anything to do with the issue, but a very reputable source, I'm sure)
    Garcia

  16. #16
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    By the way, if you ever find yourself reaching these practical limits (or going over about a thousand characters in your application URLs) it would probably be a good idea to revise your application to make sure you are only passing parameters that are absolutely neccesary for the receiving page. In this our beloved WWW, I have seen just about everything passed in the URL, including whole chunks of HTML for the receiving page to display. Hopefuly I don't need to tell you at just how many levels that is wrong.
    Garcia

  17. #17
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, where I was referring to the limit, my knowledge is from several years ago, so I suppose we've now moved on huh?

    I have seen just about everything passed in the URL, including whole chunks of HTML for the receiving page to display.
    Well, I've never done that before, and as you've pointed out, this isn't really a good idea either

    But in that regards, all the HTML I deal with are files anyways, even something as primitive as this for example,

    Code:
    <DIV>...some text here...</div>
    So no need to actually get dirty with HTML until the last moment, within your application. If I need to refer to a file, I leave the reference in a Session variable. Now going to look over your link.

  18. #18
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The browser url length limit originated from a set of recommendation for proxy server settings many years ago which set the limit at 256. This recomendation is no longer standard, but you know how long standards last... The RFC for HTTP does not specify an actual limit. Various browser implement their own limits of course, ranging from 1000 to 10k or better.

    All from memory, but I believe the above statements to be accurate.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  19. #19
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I mentioned the GET limit, because the the initial starter of the thread set it like "Encrypting data in URL".

    And data ranges from 1000 characters, up to an article, a book, or an entire database as text.

    While POST has no limitations .

  20. #20
    SitePoint Enthusiast
    Join Date
    Mar 2004
    Location
    south
    Posts
    39
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When I mentioned I encrypt primary keys in the GET the responses seem to indicate this is unusual so I'm curious to how others handle the situations where I find I have to pass a primary key in the GET.

    An example might be when a user logs in to the app I will show him a list of his accounts. Each of his accounts is a link to the account page with the account id as a parameter in the URL. The user will clink on an account name taking them to the account page, the account page will get the account id out of the GET, decrypt the account id, and query the database account table using the account id passed showing the user his account information.

    Because there are many accounts I don't see how I could use sessions or any other method.

    Is there a bettery way?

  21. #21
    SitePoint Zealot
    Join Date
    Jun 2004
    Location
    Kansas City, MO
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What's the rational behind needing to do that??

    To prevent a user from accessing accounts that aren't his??

    Well there's your problem, you forgot the security check! You're going about the problem the wrong way. You have put security in the wrong place.

  22. #22
    SitePoint Enthusiast DamienGiles's Avatar
    Join Date
    Mar 2005
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree. What I do with my users is hash check all my values.

    e.g. index.php?page=foobar&ID=10&hash=2334551rf81435021rer5

    Providing the hash for page=foobar&ID=10 equal 2334551rf81435021rer5 then the user can browse as normal.

    This is more sanity checking then anything to avoid scripts dynamically modifying the source.

    Anything else I use $_SESSION and lock it to various things such as username, IP, useragent etc.

    If you really need to identify the user is the user then at important stages ask them to confirm a security question or reenter their password.

  23. #23
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why don't you use POST?

    Is there any special reason ...?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •