Is ActiveRecord an overkill for storing a password to vendor site?

Consider this scenario. We have an internal Rails 2 app that connects to a vendor site using Savon ( Ruby SOAP library). The connection relies on authentication using a username and password. Password changes every 30 days. Right now - every 30 days on of the developers has to go to vendor's site, update the password, and the go back to our internal rails app, update a password, push the app to the webserver and restart passenger.

We store the password as 开发者_高级运维a CONSTANT in the environment file along with a couple of more constants, specific to the web. We kind of want to offload this responsibility to a customer service manager, so that she updates the password every 30 days, the go to a little form in the app and updates the password.

What is the best way to store that password? We obviously can't do the CONSTANT in an environment file and keep reloading the app. But at the same time creating a model to store one password in a separate table seems like an overkill, also since the part of the app that make a request to vendor site - does about 1000 requests per day, and needs to be pretty fast, that means that storing that password in a table requires an extra query every time the request is made. Of course for our volume it's not a big deal, but theoretically what is the best\efficient solution for this problem, other than doing what we do now, loading it into memory on app start?

Store the (encrypted) password in a flat file. Reload the file by a signal, or on auth failure, or if more than 10 seconds passed since last reload and file's timestamp has changed. Wrap this logic into a single method like .getCredentials(). Most of the time it will just return cached login and password values.

Storing this in a proper database does look like an overkill to me.