views:

15

answers:

1

I run a site that is an implementation of a proprietary hosting+cms solution. This solution offers a nicely doc'd API that I have had several contracted programmers interface with in order to build custom extensions of the site functionality.

As such, I have had to share my API keys several times. The methods called by the API can operate on the database in a number of manners. Thus, sharing the keys with too many people presents a security risk I am trying to avoid, but I also haven't even begun to reach the point where I can afford to bring on a full-time developer. Thus, I will continue to have to share keys for a bit longer.

As such, how would I go about limiting my risk as much as possible? I know sharing with as few people as possible is the obvious answer, and I will do that as much as possible.

But in addition to that solution, how do other sites/admins go about this?

A: 

Such keys should expire on a regular interval. In the case of ssl most certificates expire after 1 year. Five years is more than enough to prevent the threat of Brute Force, even if you are using a small key space. However, if any any point your server is compromised you should regenerate your keys, as well as change all passwords.

Rook
Thank you for the insight, but I am at the moment more concerned with the fact that I have to give my keys to contractors (a necessary evil, I suppose) and thus the number of users that could run malicious XML-RPC calls to my database is (slowly) increasing. I dont expect any harm from these folk most likely, but as I new to all of this - was wondering if anyone had any insight on appropriate actions to take.
@user444835 change all of your keys and passwords ASAP. If the behavior doesn't stop you maybe backdoored, and then you'll need to pay a security expert to track down the problem.
Rook