2

When creating API tokens, one can pick any format one likes. Many people choose to use 40 random characters.

I'm wondering how much of a security issue is to prefix the API key with a prefix "leaking" it's use-case?

E.g. if I were to use 40char tokens I could do:

'myproj-refresh-'+random_chars(40). So that the resulting token will be myproj-refresh-F10E2821BBBEA527EA02200352313BC059445190.

This allows me to

  1. detect the API key in other people's source code (and invalidate it)
  2. minimize the number of false-positives of such a token

What I'm worried about is that if it leaks, it's not just a random number, that can be anything, but rather a thing that has an obvious meaning. It's a refresh token for "my project".

Do you think it's a viable trade-off or should it be prevented?

2

Some rapid fire thoughts:

  1. Certainly, adding a prefix doesn't make the API token more guessable, so there is no immediate security concern (compared to say, replacing the first X digits of the API token with your prefix, which would reduce entropy)
  2. There could be a minor negative side-effect if an attacker finds the key in someone else's source code before you do, recognizes that it belongs to your service because of the prefix, and therefore knows exactly where to use it. However, an attacker in such a case could probably figure out what service the token went to anyway (since they have access to source code), so I doubt this is a serious concern.
  3. Practically though, it seems like you finding your own API token in such a way is an event that will almost never happen. Are you planning on creating bots to scan all major public code repositories for your API tokens regularly? If not I doubt you'll ever find any of your API tokens, even if they are placed in someone's code somewhere.
  4. One last note, automatically invalidating someone's API token for your service if you find it leaked may be a bad idea anyway. Doing so would effectively disable their integration with your service, which might be very surprising to them, harmful to their business, and may violate your own terms of service (giving them a reason to sue). You would be much better of simply contacting them about the issue. Don't be surprised if that is not very effective though.

Summary: Does this carry a security risk? I personally don't think so. However, I also don't think it will have much practical benefit. Then again, the "cost" of doing this is probably also very low, so do it if it makes sense to you.

  • I won't do the scanning myself :) help.github.com/en/articles/about-token-scanning – Tomáš Fejfar Sep 18 at 14:08
  • @TomášFejfar Oooh, fancy. Of course they are only one of many code hosting providers :) – Conor Mancone Sep 18 at 14:14
  • @TomášFejfar although the fact that such a service is available on github means that this is officially a "thing" now, and may become more common from other services. I'd say, therefore, that that is a point in favor of doing it. – Conor Mancone Sep 18 at 14:15
  • Also regarding the invalidation - we will probably automatically invalidate tokens that belong to internal users and notify users. – Tomáš Fejfar Sep 18 at 14:16
  • 1
    Yes, I hope this will be "a thing" soon. Which is why "common token format" token is a no-go. It will report most of the code that way and will effectively be equal to DDOS of my endpoint handling it :D – Tomáš Fejfar Sep 18 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.