Every once in awhile I will have a task that involves storing a password in the Drupal database, maybe so that a module can connect to a server or service. Unfortunately it is not secure to store sensitive information in the database unless it is encrypted. So tonight I wrote and released the Encrypt module
Drupal core does store passwords in the database: the user passwords. But this is one-way encryption, or creating a hash, meaning that once encrypted there is no built-in way to retrieve the data that was hashed. You can only compare hashes, hence why Drupal does not allow you to retrieve a lost password, simply it offers the ability to reset it.
Two-way encryption, or just encryption is the idea of taking a message, altering it so that it is unrecognizable usually with some sort of key, then sending it someone that also shares that key and can decrypt the code to get the original message. There are many methods of encryption, and it's hard to know what method is best.
Why do we need encryption? Well, let's take for instance the example above. I want the user to enter in their password for an FTP site so that I can get some files from it once a day. But, I don't want the user to have to come to the site and enter in their password every day to do this. Ideally I want to be able to store that password and retrieve it when I need it. This is where encryption comes in. We don't want to store the password in the database if it is not encrypted because your database may be compromised (and there is no reason to allow the database hacker to have access to the FTP account as well). With encryption, we can create a ciphered text and store that in the database and retrieve when necessary, given that we still have the correct key.
There are no native functions in Drupal to handle encryption. I don't actually know why, but I would speculate because PHP does not have native functions for encryption without the mcrypt extension. Mcrypt is very often already compiled with PHP, but not always. Also, its encryption and is complicated, so there is a lot of weight riding on these functions.
So, I have had this idea for a long time: An encryption module to provide two-way encryption for Drupal. And tonight happen to be the night that I saw it all laid out in front of me.
The Encrypt module basically allows a developer to encrypt and decrypt data with the two easy functions:
and, then the decrypt function:
There are parameters for options, but no options should be necessary. Also, the encryption method is stored with the encrypted string, meaning that developers need not worry about tracking what methods are used. In fact, it is suggested to simply just use the default method for the site, which can change at any point.
Encryption methods are just implementation of hooks. You can look at the project page or documentation in the code to see exactly what the hooks are, but the basic idea is creating a name a callback for the encryption method.
I realize that this is an API module, and that the only real people using it will be developers. The unfortunate part is that Drupal's module management does not really handle dependencies and version compatibility all that well. Granted I am not offering a solution, as it is a tough problem, but I know that this fact will keep this module form being adopted when I know there are many cases where it could be used.
Thanks for listening and hope you enjoy the module.
Unless otherwise noted, all content on this site is licensed under Creative Commons Attribution-Share Alike 3.0.
Please see the legal page regarding more in depth information on copyrights or other relevant laws.
Two-Way Encryption
How can you decode? If the key is stored in the database, as I'm guessing it is, then thats just one more small hoop to jump through to get the data. A hacker can easily use the decrypt() function and get the info back.
Also watch this.
http://news.ycombinator.com/item?id=748164
Yes
As I was going to bed last night, I realized that using the key from Drupal's variables is not really secure, since it is stored in the DB as well. So, a solution that writes to a file would be the better, I think. I know you are probably thinking that someone that gets access to the database, probably will have access to the file structure, but the whole point of this module is to create more points of security.
Alternative module
Just curious - Did you consider the existing AES module (http://drupal.org/project/aes) and, if so, is there a reason why you decided not to use it? I can see that your module is potentially more extensible, but if most people use the Mcrypt encryption, because that's what they have available, the resulting functionality seems about the same.
Mcrypt
Last time I checked mcrypt does not come with PHP by default, though it is most often bundled with it. Nonetheless, the goal is to create a method that is extensible, serves teh single purpose of encrypting and decrypting, and not limited by PHP extensions, so that it can be a real dependency for other modules.