3

My business partner and I are building a webapplication. We have partnered with some third party services which make use of API (public and secret) keys.

The freelance developer we worked with required the keys to implement these services. Unfortunately the relationship with this freelancer took a turn for the worst and he is now blackmailing us by threatening to share those keys.

My business partner is a marketeer and I am a UI designer so we know little to nothing about this topic. How can we prevent a situation like this in the near future?

We'd like to be able to share sensitive resources such as API keys with confidence and with little risk.

P.s. we've already asked our partners for new keys.

4
  • 1
    Security aside, it sounds like you should get a lawyer on the phone, and possibly the police.
    – anon
    Commented Jul 15, 2019 at 17:07
  • 3
    Security not aside, you can't change your API keys? Most services I've used make it quite trivial to revoke old keys and assign new ones; with revoked keys, he can't do any damage.
    – anon
    Commented Jul 15, 2019 at 17:08
  • Thanks for the quick comments! We will be undertaking legal actions and new keys are in the making. He has signed an NDA and there's proof of his blackmailing attempts. What I am most interested in is how we could share such sensitive resources with external developers in the near future without such risks.
    – Peter
    Commented Jul 15, 2019 at 17:18
  • Switch to a service which makes it easy to rotate keys. That's just generally good security practices; your key could leak through any number of ways. If your service makes it more difficult than 4-5 clicks (click an X, click confirm, click "new key", click OK, copy/paste) and especially if they require you to talk to an employee, they are doing security stupidly and should not be trusted.
    – anon
    Commented Jul 15, 2019 at 17:19

1 Answer 1

5

The exact procedure you follow will necessarily change depending on the service you use. However, there are some common precautions you can take:

  • Switch to services that have robust, featureful key systems. Strictly from a security point of view, if it doesn't support all of the rest of the items in this list, you should look for alternatives. (Obviously, business needs and your abilities also need to be taken into account -- but only you can do that)
  • Follow the principle of least privilege -- when generating keys for the freelancer, ensure they have the minimum amount of permission required for them to do their job.
  • Make sure keys can be revoked quickly and automatically, with no human intervention required on the service's side. This allows you to react to bad actors. In this case, if you can easily revoke the freelancer's keys, they no longer have anything to hold over your head, just a meaningless string of bits.
  • Give the freelancer unique keys, so that you don't need to rotate all your keys just to revoke the one person's access.
  • Always have a second access method which can't be revoked by the freelancer for yourself/your business partner, so that they can't steal your account and hold that as blackmail.
  • Give the freelancer a test area to develop in, rather than having them work directly on the production server. Not only does this isolate their access to prevent damage, but it also prevents stupid mistakes from (however briefly) taking down your entire site -- if changes can be tested and demoed in a test environment, you'll have more confidence that they work before they're deployed to your customers.

Less directly, you should also keep regular offsite backups that freelancers don't get access to. That way, even if something is compromised, you can roll back to a non-compromised state easily.

Ultimately, you're necessarily giving someone in-depth access to large parts of your project. There's no way to do that absolutely safely, and what measures you can take depend on what the keys are used for.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .