I am posting this since I found an article that should be removed. The article is this one:
http://phpbuilder.com/columns/hillel_aftel20070510.php3?aid=1415
The short reason for the article to be removed is that it provides a false sence of security, and that it is worse than no security at all. Anyone with little knowledge of security and encryption would recognize this and avoid the method that article describe, but people that are new to it would probably use it since it sounds good.
If you do know about encryption you could stop reading here. If you want more information about some of the errors in the article please read on.
The long reason contains quotes from the article and information why it is wrong.
GET requests are the method of choice in cases where the data to be transmitted is relatively short, since they allow you to send data simply by writing it into a URL.
GET requests are the method of choise only if you want to have the possiblity to store the link and get the same page another time or on another computer. POST requests are preferred in all other cases. It doesn't have anything to do with the length of the data.
This script will not use the same encryption scheme every time it's used. For example, if you encode the same word twice, there is only a 1 in 10 chance that the encoded string will look the same each time. This adds an element of randomness that makes the encryption harder to crack.
It does indeed make it harder to crack. But not much. Instead of a second you would need 10 seconds to crack it. The same encryption schemes are used every time, not a new one. The result is that it is easy to crack.
With regard to encoding, there are many different ways to go about it. One way is to perform a series of mathematical operations on the data. However that method carries several disadvantages, or at least, several complications: such as unpredictable output length, and the difficulty of working mathematically with non-numeric ("string") data.
...
So in order to encode or decode a character, the function simply needs to look up that character's ASCII value in the array, rather than perform a series of calculations.
The calculations are used to provide security, by removing it you basically remove the security at the same time.
In order to tell the decoder function which data set was used, we will "tag" our encoded data with a character placed at a specific position within the encoded string. When the decoder reads the character at that position, it will be able to determine which data set it needs to use to decode the data. We'll also pad the left and right sides of the encoded string with random dummy digits, just to add some additional confusion.
Basically this part says that it is easy to crack the "encryption", it is just a matter of finding where that character is hidden.
You now have the tools you need to take full advantage of the convenience of GET requests, without ever needing to display insecure data in the client browser.
You should never send insecure data to the client without using HTTPS. And you should defenetley not send insecure data to the client if the client should not be able to see the data.
I hope this post will result in getting the article read through by an admin that knows encryption, and that they decide to remove the article. As commonly known people that develope encryption algorithms are either a genious or a person that think he is one. I would not put the writer of the article in the first category...
