I recently made the mistake of leaking my Mailgun API key in an open-source GitHub project. I immediately invalidated it, but Mailgun support has asked me to take the additional step of deleting my GitHub repository. So far they have refused to re-activate my sending domain until I do this.

Why is this so important? It's admittedly embarrassing to have that in my public record, but how could it be used against me?

Update: Mailgun is now telling me that an old API key is not a problem.

  • 3
    If an API key isn't valid anymore, by definition, nobody should be able to reuse it. Accidental leakage like you described is exactly one of the reasons why providers allow you to explicitly invalidate API keys. (But there could be something special about the Mailgun API so that their key invalidation doesn't do what it is supposed to do.)
    – Arminius
    Commented Jan 19, 2018 at 23:38
  • 1
    Will they also check anyone that forked your repository in the past, both on github on other private servers? Commented Jan 19, 2018 at 23:41

2 Answers 2


Either it's safe to publish an old API key on the title page of New York Times, or they don't actually have a correct invalidation procedure.

Users often stick with API keys for years, almost nobody's going to replace them unless something really bad happened to those keys, e.g. they were stolen or leaked. In this case, a new key would be issued and an old one must not be valid anymore (hence invalidation) for anything API-related from the very moment a new key was issued. Add an hour or, heck, even a day for all sorts of CDNs and caching, it still has nothing to do with deleting a Github repo.

Regarding some suggestions in comments,

New keys may be computable from old keys

An API key itself is just a random sequence of bytes. A new key should probably be computable from nothing except pure enthropy. Anyway, an old key is a wrong base for new keys. If a new key depends on those old ones, they'd better think once more on the design of their API auth.

Mailgun may be afraid that people will try the old keys against their server, which would increase the server load.

Anyone can try an arbitrary random sequence of bytes against an API server. Processing an invalid API key once in a while must be affordable for an auth server. There are also methods and even products which help to protect against brute force if it's a real problem. I don't think having an old key leaked will somehow significantly influence the server load (except if their only server is a Raspberry Pi instance).

What if the key isn't leaked but stolen? Do you have to convince the thief to delete an old invalid key from their databases? This is ridiculous. Mailgun has no reason to require that.


Can old API keys be used to weaken security

There are many ways old keys could pose a risk, and as Mailgun support are insisting you delete the repo this seems to imply they think it is a risk.

  • New keys may be computable from old keys
    • It may be that knowing an old key makes breaking a new key easier (this would depend on how the keys are generated)
  • Old keys may not be invalidated immediately (or at all)
    • The servers may cache valid keys, and this cache may not be invalidated immediately, so old keys may be used to access the service until the keys leave the cache.
  • Mailgun may be afraid that people will try the old keys against their server, which would increase the server load.

Should old API keys pose a risk

Old API keys should not pose a risk if they are generated in a sensible way, for the part above I assumed they are not generated in a sensible way, because Mailgun seem to think that it is a risk, and they know more about how their API keys are generated

You must log in to answer this question.

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