Encoding vs. Encryption
Encoding and encryption are both routines performed on data, however the end results are quite different. In the case of encryption the purpose is to disguise the data such that it can’t be read, except by the intended recipient. On the other hand, encoding is used merely to work the data into a more suitable format. Sometimes these methods are used in conjunction, as we’ll see later in this article, but frequently developers mistakenly substitute encryption with encoding, which can cause some very serious security issues.
While there are many different encoding algorithms, one of the most widely used in web development is base64. As the name suggests, base64 maps 6-bit blocks of binary data into 64 different character representations. The phrase “hello world!” in base64 encoding appears as “aGVsbG8gd29ybGQh,” a somewhat random looking set of characters. However, if we examine the string in more detail we see right away that a very limited set of characters are in use, and applying base64 decoding gives the original “hello world!” message back.
<?php
echo base64_encode("hello world!"); // prints aGVsbG8gd29ybGQh
?>
A typical application for encoding is transmitting binary data across the Internet. If not encoded, the binary data will likely become corrupt. This is because some systems may interpret the data differently. To ensure this doesn’t happen we can encode the data before sending it, and decode it upon arrival.
It’s important to point out that encoding should never be used in place of encryption. The reason for this is due to the very nature of encoding, which allows data to be easily converted from one representation to another. Only the algorithm is needed, no key is required. To an attacker, it’s like coming across a front door with a dozen knobs and no lock. The only thing standing between them and what’s inside is finding the right knob to turn.
When storing or transmitting sensitive information encryption should always be used. As with encoding algorithms there are many different encryption algorithms (ciphers), perhaps even more than the former. It’s worth noting that ciphers typically have very short life spans, and while popular ciphers in use today have withstood rigorous attacks, it’s likely that will not always be the case.
What makes a good cipher is high entropy. The more random a string appears, the more difficult it is to crack. Because of this many encrypted strings contain unreadable characters, which can often be lost or corrupt when transmitting or reading. To prevent that from happening we can encode the encrypted string into a readable format before storing or transmitting. Anyway, let’s take a look at an example.
Our “hello world!” phrase, encrypted using the AES cipher looks like “R4OuDkO7P5Z6fLHzpuC8ZQ==” in base64 encoding, or “4783ae0e43bb3f967a7cb1f3a6e0bc65” in hexadecimal (I’ve left out the plain-text representation here because it contains almost no readable characters). The only way to convert this data back into its original form is to decrypt it using the same algorithm and key that was used to encrypt it. Since the key is kept private, an attacker will have a very difficult time recovering the plain text even if he knows the algorithm used.
It’s easy to mistake an encoded string with an encrypted string, especially if we assume an attacker has no idea what encoding is being used. For example, if we take our base64 encoded “hello world!” string and reverse it we get “hQGby92dg8GbsVGa.” An attacker may recognize this as a base64 encoded string, and it is a valid one, however, simply decoding this without first reversing the string will result in what appears to be a random collection of characters. While this may deter some attackers, it’s absolutely no substitute for encryption.
<?php
$a = strrev(base64_encode("hello world!")); // $a = hQGby92dg8GbsVGa
echo base64_decode($a); // prints unreadable characters
echo base64_decode(strrev($a)); // prints hello world!
?>
Related Tags:
Saasdir Award, Part Quatre
Blesta won the saasdir.com award again, for July 2009. That’s 4 months in a row! Check it out and place your vote for us for August.
Related Tags:
Saasdir Award, Part Trois
Blesta won the June 2009 saasdir.com award. That’s 3 months in a row! Check it out and share some vote love.
Related Tags:
Gateway changes in 2.2
As Paul recently announced on our forums, multi-currency support is coming in version 2.2. This is a major change and affects just about every aspect of Blesta. For this reason a few minor changes have been made to the way gateways are written to accommodate multi-currency support. If you plan to upgrade to version 2.2 and are using any gateways not listed in our
official gateways listing, you should closely examine the following changes and contact us if you have any questions so you can make a smooth transition into version 2.2. All gateways must now extend the following abstract Gateway class:
<?php
abstract class Gateway {
/**
* Returns all currencies supported by this gateway.
*
* @return array An array of currencies supported by this gateway
*/
abstract function getCurrencies();
/**
* Returns all gateway settings fields
*
* @return array An array of all configurable fields
*/
abstract function getSettingFields();
}
?>
Changes for Non-Merchant Gateways 1. Must now extend the Gateway class. 2. Must define the getCurrencies() method. 3. Must return the currency used in the process() method as part of the return array (i.e. $trans[‘currency’] = “USD”). Changes for Merchant Gateways 1. Must define the getCurrencies() method. 2. Must define the getSettingFields() method. This method is implemented exactly as it is currently implemented in Non-Merchant gateways. Below is an example implementation of the getCurrencies() method:
<?php
// All currencies this gateway accepts
private static $supportedCurrencies = array("AUD", "EUR", "JPY", "USD");
public function getCurrencies() {
return self::$supportedCurrencies;
}
?>
You must also be sure that your gateway is POSTing the currency to your gateway in the appropriate manner. The currency will be fed to your gateway in the constructor’s 1st parameter as ‘currency’ (i.e. $gatewayinfo[‘currency’]). Failure to do so may result in your gateway processing your transaction in the incorrect currency, or a failed transaction. Again, this article only applies if you are using an unofficial or custom gateway and plan on upgrading to version 2.2. All gateways packaged with 2.2 will already contain these changes.
Related Tags:
Saasdir Award, Part Deux
Blesta won the May 2009 saasdir.com award. That’s 2 months in a row! Check it out and share some vote love.