Wordpress - How to store username and password to API in wordpress option DB?

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

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.