3. Why API Keys Are Not Enough

API Keys are often misused as a security feature, but they primarily serve as identifiers rather than providing robust security. Relying solely on API Keys can lead to significant vulnerabilities due to the shifting of responsibility to developers and a lack of granular control. For high-use APIs that require more than just read access, alternative solutions for authentication and authorization are necessary to ensure security.

Uploaded by

work job

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

3 views

3. Why API Keys Are Not Enough

Uploaded by

work job

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 7

API Keys ≠ Security: Why API

Keys Are Not Enough

by Kristopher Sandoval
Originally Published Here

Who holds the key? APIs need robust identity control and access
management.
We’re all accustomed to using usernames and passwords for
hundreds of online accounts — but if not managed correctly,
using passwords can become a significant distraction and a
potential security vulnerability. The same is true in the API space.
There’s nothing inherently wrong with usernames — you need
those. But if you use them without also having credentials that
allow the service to verify the caller’s identity, you are certainly
doing it wrong.
Unfortunately, many API providers make a dangerous mistake
API Keys ≠ Security: Why API Keys Are Not Enough 23

that exposes a large amount of data and makes an entire ecosys-

tem insecure. In plain English — if you’re only using API keys,
you may be doing it wrong!

What is an API Key?

An API Key is a code assigned to a specific program, developer

or user that is used whenever that entity calls an API. This Key is
typically a long string of generated characters which follow a set
of generation rules specified by the authority that creates them:

1 IP84UTvzJKds1Jomx8gIbTXcEEJSUilGqpxCcmnx

Upon account creation or app registration, many API providers

assign API keys to their developers, allowing them to function in
a way similar to an account username and password. API keys
are unique. Because of this, many providers have opted to use
these keys as a type of security layer, barring entry and further
rights to anyone unable to provide the key for the service being
requested.
Despite the alluring simplicity and ease of utilizing API Keys
in this method, the shifting of security responsibility, lack of
granular control, and misunderstanding of the purpose and use
amongst most developers make solely relying on API Keys a poor
decision. More than just protecting API keys, we need to program
robust identity control and access management features to safe-
guard the entire API platform.

Shifting of Responsibility

In most common implementations of the API Key process, the se-

curity of the system as a whole depends entirely on the ability of
API Keys ≠ Security: Why API Keys Are Not Enough 24

the developer consumer to protect their API keys and maintain

security. However, this isn’t always stable. Take Andrew Hoff-
man’s $2375 Amazon EC2 Mistake that involved a fluke API key
push to GitHub. As developers rely on cloud-based development
tools, the accidental or malicious public exposure of API keys
can be a real concern.
From the moment a key is generated, it is passed through the
network to the user over a connection with limited encryption
and security options. Once the user receives the key, which in
many common implementations is provided in plain text, the
user must then save the key using a password manager, write
it down, or save it to a file on the desktop. Another common
method for API Key storage is device storage, which takes the
generated key and saves it to the device on which it was re-
quested.
When a key is used, the API provider must rely on the developer
to encrypt their traffic, secure their network, and uphold the
security bargain’s side. There are many vulnerabilities at stake
here: applications that contain keys can be decompiled to ex-
tract keys, or deobfuscated from on-device storage, plaintext
files can be stolen for unapproved use, and password managers
are susceptible to security risks as with any application.
Due to its relative simplicity, most common implementations of
the API Key method provide a false sense of security. Developers
embed the keys in Github pushes, utilize them in third-party
API calls, or even share them between various services, each
with their own security caveats. In such a vulnerable situation,
security is a huge issue, but it’s one that isn’t really brought up
with API Keys because “they’re so simple — and the user will keep
them secure!”
This is a reckless viewpoint. API Keys are only secure when used
with SSL, which isn’t even a requirement in the basic imple-
mentation of the methodology. Other systems, such as OAuth
API Keys ≠ Security: Why API Keys Are Not Enough 25

2, Amazon Auth, and more, require the use of SSL for this very
reason. Shifting the responsibility from the service provider to
the developer consumer is also a negligent decision from a UX
perspective.

Lack of Granular Control

Some people forgive the lack of security. After all, it’s on the
developer to make sure solutions like SSL are implemented.
However, even if you assure security, your issues don’t stop
there — API Keys by design lacks granular control.
Somewhat ironically, before API keys were used with RESTful
services, we had WS-Security tokens for SOAP services that let
us perform many things with more fine-grained control. While
other solutions can be scoped, audienced, controlled, and man-
aged down to the smallest of minutia, API Keys, more often than
not, only provide access until revoked. They can’t be dynami-
cally controlled.
That’s not to say API Keys lack any control — relatively useful
read/write/readwrite control is definitely possible in an API Key
application. However, the needs of the average API developer
often warrant more full-fledged options.
This is not a localized issue either. As more and more devices are
integrated into the Internet of Things, this control will become
more important than ever before, magnifying the choices made
in the early stages of development to gargantuan proportions
later on in the API Lifecycle.
API Keys ≠ Security: Why API Keys Are Not Enough 26

Square Peg in a Round Hole

All of this comes down to a single fact: API Keys were never
meant to be used as a security feature. Most developers utilize
API Keys as a method of authentication or authorization, but the
API Key was only ever meant to serve as identification.
API Keys are best for two things: identification and analyt-
ics. While analytic tracking can make or break a system, other
solutions implement this feature in a more feature-rich way.
Likewise, while API Keys do a great job identifying a user, other
alternatives, such as public key encryption, HoK Tokens, etc. do
a much better job of it while providing more security.

The Pros of API Keys

There are definitely some valid reasons for using API Keys. First
and foremost, API Keys are simple. The use of a single identifier
is simple, and for some use cases, the best solution. For instance,
if an API is limited specifically in functionality where “read” is the
only possible command, an API Key can be an adequate solution.
Without the need to edit, modify, or delete, security is a lower
concern.
Secondly, API Keys can help reduce the entropy-related issues
within an authenticated service. Entropy — the amount of en-
ergy or potential within a system constantly expended during
its use — dictates that there are a limited amount of authenti-
cation pairs. Suppose entropy dictates that you can only have
6.5 million unique pairs when limited within a certain charac-
ter set and style. In that case, you can only have 6.5 million
devices, users, or accounts before you run into an issue with
naming. Conversely, establishing an API Key with a high number
API Keys ≠ Security: Why API Keys Are Not Enough 27

of acceptable variables largely solves this, increasing theoretical

entropy to a much higher level.
Finally, autonomy within an API Key system is extremely high.
Because an API Key is independent of a naming server and
master credentials, it can be autonomously created. While this
comes with the caveat of possible Denial of Service attacks, the
autonomy created is wonderful for systems that are designed to
harness it.
When developing an API, a principle of least privilege should
be adhered to — allow only those who require resources to
access those specific resources. This principle hinges on the
concept of CIA in system security — Confidentiality, Integrity,
and Availability. If your API does not deal with confidential infor-
mation (for instance, an API that serves stock exchange tickers),
does not serve private or mission-critical information (such as
a news/RSS API), or does not demand constant availability (in
other words, can function intermittently), then API Keys may be
sufficient.
Additionally, API Keys are a good choice for developer-specific
API uses. When developers are configuring API clients at oper-
ation time, and use changing keys for different services, this is
acceptable.

Back to Reality

The benefits of using API Keys outlined above are still tenuous in
the general use-case scenario. While API keys are simple, the lim-
itation of “read-only” is hampering rather than liberating. Even
though they provide higher levels of entropy, this solution is not
limited to API Keys and is inherent in other authentication/au-
thorization solutions. Likewise, autonomy can be put in place
through innovative server management and modern delegation
API Keys ≠ Security: Why API Keys Are Not Enough 28

systems.

Conclusion: API Keys Are Not a Complete

Solution

The huge problems with API Keys come when end users, not
developers, start making API calls with these Keys, which more
often than not expose your API to security and management
risks. It comes down to that API Keys are, by nature, not a com-
plete solution. While they may be perfectly fine for read-only
purposes, they are too weak a solution to match the complexity
of a high-use API system. Whenever you start integrating other
functionality such as writing, modification, deletion, and more,
you necessarily enter the realm of Identification, Authentication,
and Authorization.
Basic API Key implementation doesn’t support authentication
without additional code or services. It doesn’t support authen-
tication without a matching third-party system or secondary
application. It doesn’t support authorization without some se-
rious “hacks” to extend use beyond what they were originally
intended for.
While an argument could be made for expanding out the API
Keys method to better support these solutions, that argument
would advocate re-inventing the wheel. There are already so
many improved solutions available that adding functionality to
an API Key system doesn’t make sense. Even if you did add some-
thing like authentication, especially federated authentication,
to the system using Shibboleth, OpenID, etc., there are a ton of
systems out there that already have support for this.