Setting up a web application to automatically run authenticated calls over HTTP to a remote website without repeated human authentication

I want to be able to set up a web application to automatically (i.e. on a cron run) send a POST request to a remote website. The remote website requires a username/password combination to be sent as part of the POST data. I want the web application to be able to make the POST requests of the remote website without requiring the user to provide the password to be sent with the POST data, each time the request is made.

It seems to me that the only way to do this is to store passwords directly in the database, so that the cron run can execute a POST request that includes the password as part of its POST data. Without storing the password in some form in the database, it seems it would be impossible to provide it in the POST data, unless the user provides it each time the request is made.

Question 1: Am I mistaken and somehow overlooking something logical? Question 2: Assuming I have to store the passwords in the database, what is the safest procedure for doing so? (MD5 and similar one-way encryption clearly will not work because I have to send an unencrypted password in the POS开发者_如何学PythonT request.)

Thank you for your help!

---

a. if you don't know the password... you can't authenticate, that's the idea of a password !

b. if you need to know the password - you need to save it in a decryptable way - hence - less secured.

c. if you own the site, you can use a cookie with a very long timeout value, but - you still need to authenticate at least once.

d. unless you're guarding money / rocket science, you need to encrypt the password and store it in the DB and decrypt it every time before use, at least you are guarded from DB theft.

e. make sure you're authenticating over secure channel (as https) so the password will no be sent as clear text.

---

One good solution is probably to use SSL (i.e. HTTPS). You can create a certificate authority on the server side, then have this certificate authority sign a client certificate that you generate. Make sure the HTTP server is configured to trust the newly created certificate authority.

Once this is done, you should install the certificate on the client side. The client must present the certificate when talking to the HTTP server. You have to configure the HTTP server to require a trusted certificate when POSTing to your secure URLs.

Awesome example of how to do this with Apache HTTPD is posted right here!

The document I linked doesn't describe how to set up the certificate authority and create self-signed certificates, but there are tons of examples out there, for example here.

This is a good solution because:

• no passwords are stored in the clear
• if the private key of the client's certificate is stolen or compromised, you can revoke it on the server side

The key here is that the client is providing its credentials to the server, which is the opposite of what is usually done in a browser context. You can also have the client trust your newly created certificate authority so that it knows it's talking to the right server and not a man in the middle.

---

Given that you have to send the password in clear-text and do it repeatedly without user-interaction you'll need to store and retrieve the same from a data-store (file/database/memory).

What you really need to consider is the last-line-of-security of the password store.

Whether you encrypt it or not doesn't matter. The person/program with access to the data or the cipher key will be able to read that password.

Sort this issue out, document it - (this becomes your security policy for the app) and then implement it.

Security is only a level of difficulty you implement to lessen a risk.

---

Fortunately, Tumblr now implements OAuth, which solves this problem.