3

I have a custom module that saves variables with FTP usernames and passwords. Is variable_get secure? Ie. Can it be accessed outside of the module.

Is variable_set equally secure?

Obviously they are being saved to the database and are only as secure as the DB but I'm assuming the DB is secure.

  • 1
    question is not whether variable_get or variable_set is secure, but rather your FTP connection is secure or not. – Minty Jul 26 '12 at 13:49
0

All variables set using variabe_set() will be stored in DB, then retreived and assigned to global variable $conf.

function variable_get($name, $default = NULL) {
  global $conf;    
  return isset($conf[$name]) ? $conf[$name] : $default;
}

Unless you have a content type that allows users to add PHP scripts this is secure enough.

I'm assuming the DB is secure.

What if entire DB is exposed by a SQL injection attack ? Always store sensitive data in encrypted format so that even if it gets hacked it will be of no use to the attacker. You should not store the password as a plain text in database. Use any encryption algorithm to store them.

  • 1
    And where do you store the encryption key, as a variable? ;) – Berdir Jul 26 '12 at 6:10
  • You can use s secure MS SQL DB to store the key. Write a Java service that will connect to MS SQL and retreive the key :P – GoodSp33d Jul 26 '12 at 6:23
  • 1
    Yes, something like that would work, you don't even need a database, you can just write a small program that asks for the key on startup and stores it in memory. However, that's a rather complicated setup for an FTP password, which is then submitted to an external server without any kind of encryption :) – Berdir Jul 26 '12 at 8:38
6

I suggest not storing this information with a variable_set or system_settings_form which will put it in the variable store (which is the database by default, and can be cached wherever caching is happening such as memcache).

Instead, I suggest using the $conf array in settings.php for the information. The benefit is that settings.php is a file you are already using to store credentials for the database and already protecting from prying eyes.

The beauty of this system is you can still use variable_get to load the value from $conf which is easy, handy, etc.

For more details read the settings.php file itself which has a lot of commented out code examples and documentation.

5

Don't save FTP password in database as is - encrypt it using mcrypt (http://www.php.net/manual/en/mcrypt.examples.php) or other library and store encryption cipher in code.

Examples.

Save FTP password

$encrypted_password = mcrypt_ecb(MCRYPT_3DES, $cipher, $form_state['values']['password'], MCRYPT_ENCRYPT);
variable_set('ftp_password', $encrypted_password);

Load FTP password

$decrypted_password = mcrypt_ecb(MCRYPT_3DES, $cipher, variable_get('ftp_password', ''), MCRYPT_DECRYPT);

Note: $cipher must be somewhere defined in module code.

1

All of these variables that you get via variable_get are stored in variable table, and loads everytime Drupal starts. Site Name, main email address, and other module configurations are stored in this table but NOT encrypted.

variable_get works anywhere in the site - in page templates, custom php blocks, etc.

The best way to protect your password is to not retrieve the password anywhere other than the FTP implementation. For an example, in admin forms, we use variable_get('form-element-key-here', '') as the default value. So forms look like it stored configuration. Do not do this for the password field. You can see the same technique used in SMTP authentication module and PHPMailer module. http://drupalcode.org/project/phpmailer.git/blob/refs/heads/7.x-3.x:/phpmailer.admin.inc

Unless you leave Devel module enabled and insecure, nobody with php or database access can see your password.

0

In short, it's just a function to store/retrieve info from a specific table in your database. Your whole database is accessible from every module/template/... within your Drupal instance.

Some advice might be to keep in mind what do you want to store in your db. You mentioned that you're assuming the db is secure, and that is the biggest part of all.

As already mentioned, better to encrypt that kind of data before storeing it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.