Possible Duplicate:
How should passwords be stored if they must be recoverable?
I have created an API for a site that doesn't provide any form of API. For the API to do anything with the account, it needs the username and password in plaintext.
How should I store this password so it can be provided to the API?
It should be available to my server, which runs a cronjob every hour, that is using this API.
Edit: I only need to store my own password for this site.
How do you store the password? Very carefully.
In particular, I suggest using a special architecture:
Set up a separate machine, which will exist only for storing the cleartext passwords. It should be hardened and locked down as tightly as possible. You should limit the number of administrators with access to this server. And this server should be used only for this purpose. Let's call this the "login server".
The login server should export a simple API, with a few functions: (a) add a new username/password pair for some website to the password store, and return a handle that uniquely identifies this; (b) login to the third-party site using a particular username/password pair (as specified by its handle), issue a particular request, and return the response; (c) delete a particular username/password pair (as identified by its handle). Passwords should be stored on the login server (not on a shared database).
Notice that there is no API to export a username/password pair from the password store. That is on purpose. The login server should act as a Hotel California for passwords: passwords go in, but they never come out.
The login server should keep detailed logs of all uses of its passwords. You might also want to have it to some rate-limiting (e.g., notify an administrator if the rate of uses exceeds some threshold). And you might want to have some garbage-collection, so that if a username/password is not used within 90 days, you delete it from the password store, to limit the number of old passwords stored (the user can be prompted to re-enter their username/password when they next log in).
This architecture isolates the most security-critical aspect into a separate piece, the login server, and tries to keep its functionality as simple as possible, so that you can minimize the chances of security vulnerabilities that might allow access to users' passwords.
Second, I suggest that you plan to do an extra level of code review and testing, given the critical nature of the login server:
Have a second developer review all of the code for the login server, to check that it does not contain any security vulnerabilities.
Consider hiring someone to do a pentest or a security code review of the login server.
Even if you take all of these steps, you are still subject to some risk. There is no silver bullet. If the login server gets hacked, all of your users' passwords will be disclosed, which is very bad. Therefore, be as careful as you can.
There is no other option I think then to store your own user password plain text. If you want to use a crypto you will need to store the key somewhere on your server so your cron job script can access and see it. You should store the password plain, but make sure that the only person that can read the file is the account that the script runs under. This should be a separate user without shell who's solely purpose is to run this script. In that way the only two users that will be able to read the file is the script user and the super user on the machine.
