August 8th, 2008, 08:09 AM
Encoding URL variables in a PHP/C# compatible way
I've had nothing to do with encryption/encoding before, so would be grateful if anyone could point me in the direction of what I should be learning to do the following:
Using PHP, I want to encrypt a string similar to the following:
so that it becomes one string that can be unencrypted by an ASPX page.
A user on the company intranet enters details into a (PHP) form that would create the unencrypted URL:
However, the encrypted URL that it does produce looks like: www.company.com/feedbackform.aspx?var=8a0a90afjafp0a49pqje9ajf093j
or something like that...
When that link is clicked on, the aspx page uses a 'key' or similar, to unscramble the 'var' string, and extract the values of the 'id', 'email' & 'client' variables.
Any suggestions appreciated!
August 8th, 2008, 11:18 AM
loads of ways of doing it, heres a few:
1: add x to each ascii character and send that, not secure but gibberish to the idle hacker (perhaps complicate it by adding 5 + pos of character etc etc).
2: If you trust the integrity of both ends then generate and store the same secret key on the server and all clients and use AES or similar to encrypt with said key, secure so long as no hacker can get the key
3: If you only trust the server then generate an asymmetirc key and use RSA or ECC as above (with the client side only having a public key, the server having the private key)
4: Change the design so you use https and pass the data encrypted by that
The complexity of key management make me prefer solution 1 unless you really need the system to be secure. 4 would seem to be the standard method to secure data across networks.
If you do need full encryption then c# and php have libraries to generate keys, encrypt, decrypt etc using numerous algorithms.
August 13th, 2008, 12:18 PM
Many thanks - that gives me all the options to investigate I need.
Originally Posted by IamPatrick
August 13th, 2008, 01:09 PM
A much cleaner approach is to not bother to "encrypt" the query string, but rather send a nonce. and on your server, keep a hash table indexed by the nonce into a structure that has all the data fields.
So don't send a URL like
Rather call a random number generator, get a nonce, and send the URL as
Then just have a hashmap that converts
Never trust a client. So if the user/client/browser sends back the proper nonce, you are set to go. If they send a nonce that is not in your hash table, you know they are a bad guy.
Comments on this post
August 21st, 2008, 04:30 AM
Originally Posted by fishtoprecords
The above one would be much difficult to understand right? why can't we use base64 encoding and decoding?
August 21st, 2008, 12:08 PM
Its not difficult to understand.
It is not at all "the same" as base64 encoding. And if security is a concern, base64 encoding is not a cipher.
The rule is never to trust what you get from the client. Might be a browser, might be a rogue program claiming to be a browser.
With the nonce/hash approach, if the rogue studies it, they learn it is a random number. If they change it, we don't find the entry in the hashmap and know instantly that they are bad guys.