Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm currently developing a plugin and the chances are that I will more than likely release it on the public plugin repository so others can use it.

The plugin will be using an API and to use this API you need to pass a username and password. So my plugin needs to store these login credentials in the database. I don't want to store these in plain text although the API needs them in plain text.

So my question is how do I store these sensitive bit of information? Hashing is out, so it has to be some sort of encryption.

In WordPress is there a unique key that can be used that will differ from blog to blog? What php functions should I use to encrypt and decrypt? I'm looking for functions that will more than likely work on all WP installs.

share|improve this question
3  
This is kinda unsolvable. It doesn't matter how much you encrypt if it needs to be reversible. If WP can decrypt it and WP is compromised then encryption doesn't matter. –  Rarst Aug 5 '11 at 12:57
    
But why does your API need to know the password? Isn't it enough if the API knows that the user knows the password? –  onetrickpony Aug 5 '11 at 13:02
    
@One Trick Pony - The password needs to be stored so the process can be automated without user intervention. –  Brady Aug 5 '11 at 13:05
    
@Rarst - I'm aware that if WP is compromised then so are the passwords. I cannot prevent this. What I can prevent is that if an SQL dump is obtained then the passwords are not in plain text. –  Brady Aug 5 '11 at 13:08
    
@Brady yep, if only SQL dump is compromised then encryption would help. However I find such scenario unlikely. If you have database access it is trivial to compromise WP as well. –  Rarst Aug 5 '11 at 13:15

2 Answers 2

up vote 3 down vote accepted

While I agree with the previous answers, to answer the question you actually asked, what comes to mind is to use one of these constants for wp-config.php:

define('AUTH_KEY',        'redacted');
define('SECURE_AUTH_KEY', 'redacted');
define('LOGGED_IN_KEY',   'redacted');
define('NONCE_KEY',       'redacted');

They are meant to be unique across wordpress installations - and are about the only options for pre-existing keys to be found in wordpress. Alternate would be to add your own similar constant that is built by hashing one of them against the admin email address or similar - and then storing that in a hidden setting option -- to protect against losing your key if someone accidentally modifies the keys after your plugin is installed. The danger is, that if they were not made unique on the initial install, but the admin / site owner decides to rectify the failure after the fact, they shouldn't accidentally break your password encryption.

As for encryption / decryption functions - a quick Google search returns the following listing with code that appears to fit the bill: http://maxvergelli.wordpress.com/2010/02/17/easy-to-use-and-strong-encryption-decryption-php-functions/

function encrypt($input_string, $key){
    $iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
    $h_key = hash('sha256', $key, TRUE);
    return base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $h_key, $input_string, MCRYPT_MODE_ECB, $iv));
}

function decrypt($encrypted_input_string, $key){
    $iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
    $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
    $h_key = hash('sha256', $key, TRUE);
    return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $h_key, base64_decode($encrypted_input_string), MCRYPT_MODE_ECB, $iv));
}

Here's some documentation of the AES encryption used here: http://www.chilkatsoft.com/p/php_aes.asp

share|improve this answer

This is exactly the circumstance OAuth was designed for.

From the OAuth homepage:

For Service Provider developers...

If you're supporting...

  • web applications
  • server-side APIs
  • mashups

If you're storing protected data on your users' behalf, they shouldn't be spreading their passwords around the web to get access to it. Use OAuth to give your users access to their data while protecting their account credentials.

The advantage of OAuth is that you don't need to store the user's password. When they first set up the plugin, they're asked to log in with a username and password through the application (usually a page hosted on the same server as the API and loaded either in a page redirect, a thickbox, or an iframe).

Once the user is logged in, the server (your system) creates a secure key that their system (WordPress) can use to interface with the API. This key is unique to the user account and the site - and it gives the application (on WordPress) permission to do things with the API on the user's behalf without passing their authentication information each time.

If you want to see an example of this in action, check out Jetpack.

When you activate the plugin, it complains its not connected. When you "connect" it, you enter your credentials through WordPress.com and set up the OAuth interaction between WordPress and their API.

But you only have to do this once and your WordPress.com username/password is never stored in your local WordPress database.

share|improve this answer
    
Would be nice to use this but the API I'm dealing with isn't mine and they have no OAuth system in place. –  Brady Aug 5 '11 at 13:48
    
In that case your only real option is to accept that you need to store the password in the DB and whether or not you encrypt it really makes no substantive different to security. As other have mentioned above, if it's in the db and the encryption is reversible, then anyone with access to WordPress (legitimate or hacked) could conceivably get a hold of it. –  EAMann Aug 5 '11 at 16:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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