It’s time we accept as an industry that API keys and secrets are essentially usernames and passwords, except they’re designed to be used in an automated way to perform your company’s most sensitive functions, often instrumented by developers who don’t prioritize security.
They’ll probably respond, “Of course.”
Now ask them what you can do with that API.
“Oh, it’s a great API. You can do pretty much everything.”
“Great. How many people have access?”
“It’s super popular. We give access to all our developers, and any account can ask for and receive a key.”
“Cool. So how many of those keys are out there, and how do you control them?”
“…”
Exactly.
API keys often have full access to the platform, and guess what the access method is: a string of characters for your key, and a string of characters for your secret.
Sound familiar? How is this different from a username and password?
“Oh, but this is different because it’s all code-ey and stuff. Lots of programming and hard things.”
No.
That’s not a defense. Good APIs also share something else: great documentation.
It’s easy to do things like adding users, adjusting permissions, or pulling data using this interface because it’s meant to be easy. In fact, the easier it is to do something powerful, the better.
And this is all happening on 2FA-enabled accounts, despite that supposed higher level of security.
Summary
- Everyone understands that 2FA is better than just a username and password.
- Everyone is also trying to add an API to their new services.
- API keys are just usernames and passwords used in code.
- Few people realize this, and think it’s safe because “programming is hard” or because “APIs are magic.”
- APIs are not magic. They’re an entry point into your application, and there are far too many keys and secrets floating around Slack, Github, and many other places on services that are 2FA-enabled.
- This presents a false sense of security.
2FA is great. Enable it where you can. But it’s not the end of the conversation. Be sure to look at your API as well. Know what you can do with it, know who has keys, know how often they expire, and have a plan for monitoring and response.
For all intents and purposes, you should treat API access like legacy username and password access. After all, API keys and secrets are credentials.
Credentials can be stolen, and credentials can be used to do bad things.
This post is adapted from Daniel Miessler’s original blog post, which you can find at https://danielmiessler.com/blog/apis-2fas-achilles-heel/.