Generic Cipher and Encryption

Lately I needed to encrypt some data: in this case username, password, and credit card data. It them hit me that there exists. I knew that I'd be reusing the encryption settings, so why not make some external API to do all that work for me so that all I have to do is say: "Hey, encrypt this!", or "Hey, decrypt this!".

Enter the "Cipher" module. It is a basic module that basically gives a developer an API to work with via a class to do basic encryption/description. Here's a little snippet of how it works:

Say that I want to have a password field stored encrypted in a database. The insertion happened on the myform_submit hook. So, in the form, I would do something to the following effect:

function myform_submit($form_id, $form_values) {
$cipher = new PontoCipher(variable_get('mymodule_cipher_key', ''));
$form_values['password'] = $cipher->encrypt($form_values['password']);
db_query("INSERT INTO {table} VALUES('%s', '%s')", $form_values['username'], $form_values['password']);
return;
}

Now, what just happened? Well, on the first line, we created the $cipher object. You will notice that we gave the constructor a "cipher_key". This is the 'key' that is used for encryption. By default, the cipher module uses your drupal installs site key if one is not given. However, your module could use a totally different key.
Next, we asked the cipher to encrypt the values. We then inserted the ENCRYPTED information into the database.

To decrypt, we would create the cipher object as object, and give the function decrypt the encrypted information. The function will return the decrypted string value of the information given.

This is the start of a module that could have a lot of potential. Hopefully someone finds it of use.

Comments

Security

If the input data are filtered within special chars there is no problem with encryption. If someone get access to the DB you can do nothing but write your own DB. Buy metformin

Depends

If all you're storing is the public key, not a problem. It's public.

In the case of the example above with username/password, you're typically creating a one-way hash that's never decoded.

No, If you notice i'm using

No, If you notice i'm using the mcrypt lib, which entryps using the key given, and then the key must be used to decrypt in information. This is NOT a simple MD5 hash.

storage

Isn't the encryption circumvented easily since the key is stored on the same machine as the encrypted information?

Security hole

Presumably the point of this module is to protect data in case someone gets hold of the database. If so, then it doesn't help to store the key in the database because while the data would be encrypted, the intruder would have everything they need to decrypt said data (presuming they know what encryption algorithm was used).

The module allows on to

The module allows on to specify the FULL PATH to the key, meaning the key can be stored in a file on the server instead of on the server.
I used the drupal-api key as a "starting" point for "simply turning the api on", but def. not best practice.
In production we read the key from a file that's stored out-of-path of the main webserver, and can only be accessed by the web user and only the web user.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.