Update 5/12/2016: Stormpath now secures authentication to your API- without code!
Also, we have some awesome new resources for API developers building user management:
- Easy API Key Management with Node.js
- PHP API Authentication is a PITA!
- The Fundamentals of REST API Design (a presentation by Stormpath CTO Les Hazlewood)
While working on the redesign for our new Stormpath dashboard, our head of Marketing asked a good question:
I just saw a video on Devloper API experience where the presenter’s strong recommendations (per work on the Google APIs) was that APIs not require an API key. Since we already support authenticating users with username/password to Stormpath, would it be feasible for us to eliminate the concept of an API Key? I want to remove as much complexity as possible from the getting started process.
Unfortunately, whoever advocated this viewpoint (of not using API keys) probably didn’t manage a secure system (possibly because they didn’t need to?). So I thought I would share my thoughts on why Stormpath secures our API with API Keys (and so do others, like Amazon Web Services, and you should too). I also included some best practices for how we handle API keys.
Without an API Key, a Username/Password pair is usually used, and these pairs are almost always less secure: they are usually reused across many sites, they’re much easier to intercept, if compromised on one site, it could be compromised for all sites, etc.
Conversely, Stormpath API Keys have secrets that are securely randomly generated character strings over 40 characters long and have significantly greater entropy and are much harder for attackers to compromise. They are much more challenging for potential attackers than most normal 8-13 character passwords (which most attackers have pre-computed in what is known as a Rainbow Table anyway).
If your API uses username/password pairs and you want to reset your password (or are required to by an admin), every piece of software that was using your username/password pair for communication with the API instantly fails. This could be a hugely inconvenient and production-threatening side effect.
API Keys, because they are independent of the account’s master credentials, can be revoked and created at will – many API Keys can be granted to a single account. This is valuable for key rotation strategies, i.e. requiring a new key per month, or removing keys if you think one might have been compromised.
Also, because API Keys aren’t your account master credentials, if they happen to be exposed to a co-worker (e.g. a systems engineer sees the contents of your API Key when logged in to a production machine), your account master credentials are not at risk of being exposed to that co-worker (or any other potential surreptitious party).
Because username/password pairs are by nature almost always more insecure (see Entropy above), we go through additional measures in our system to make logins with them much slower on purpose: a username/password authentication for an application will take anywhere from 0.1 to 0.5 seconds on our system on purpose (depending on configuration): it exponentially increases the amount of time an attacker requires to try to break any given account.
This is virtually unnoticeable to the end-user logging into an application, but it makes it almost impossible for an attacker using brute force to compromise a single password who is trying millions of potential passwords at once (e.g. via an attack grid on Amazon EC2).
API Keys, because of their additional security (used with secure authentication schemes like digest-based authentication), have no such time restrictions. This allows API calls to be as fast as possible – a necessity for system-to-system communication.
API Key secrets are never exposed in our UI ever – they are provided on creation one time only (usually via a file download), and we give instructions to ensure that file is readable in the operating system by only a single person. This encourages a no-sharing policy and makes it much harder to acquire API keys: if the file is readable by the user only, you have to compromise an operating system account before acquiring a Stormpath API Key. While not impossible, it does increase the difficulty in compromising an API Key.
This also has a nice benefit when writing software applications that communicate with Stormpath: the Stormpath SDKs that go into your application code know how to read this file to acquire credentials at runtime. Why is this important?
Because you don’t need to expose (copy-and-paste) the API Keys into any of your project’s source code or configuration files where they can be seen by other people. They can truly stay private to you and only you (assuming you do due diligence and protect your operating system accounts as well).
Because we never expose the API Key secret in the UI ever, a download is required, and the download must be initiated (clicked) by a person. This click allows us to track who is responsible for dispensing API Keys – something important for security reporting.
I hope this is helpful!
Any questions or comments?