Methods to Securing APIKeys

Question

I have read on several methods to securing an API key like gitignore or placing in another file if using an application, but at some point if taken the time, anyone can get the key, even when apikey is in use or called, right? Other methods explain using a proxy which is well beyond my league. I am only aware of understanding the foundation of C# and JavaScript, and the thought of securing an apikey is mind boggling, as I think what is the most secure method. Recently, I wanted to start working on a portfolio for a better occupation, so I had thought of doing something with the Steam API, but couldn't find a concrete method to store this elsewhere and call it without anyone taking the idea of stealing or digging up this info. Even if I used it within JavaScript, how would I call this during unattended events, if I were to make a public website that was accessed by thousands of people.

Edit 1: Honestly, I have though about storing the key encrypted elsewhere, but then I would need a decryption method, as well as a key, which could still be a vulnerable method.

Edit 2: I understand that the key should be in clear text, as it is a cryptographic key itself. If stored on the server, is the api key stored in a path on the server, where only the web application is directed?

Answer 1

Disclaimer: I am not accredited or qualified to write about these things. Despite being able to recite these things from memory, I don't work on information security at all. It is possible that there are inaccuracies and/or misunderstandings in my writings.

---

the thought of securing an apikey is mind boggling

Yes, it is. Information security is a mental wargame between you and some unknown assailants of unknown skill level.

but at some point if taken the time, anyone can get the key, even when apikey is in use or called, right?

Yes, sort of. It is right to be paranoid about the possibilities. But not too much, since too much paranoia paralyze our thoughts and we won't be able to create anything useful.

---

Specifically:

• An API key is a "shared secret" between you and the API provider ("Steam").
• Being a "shared secret", anyone who got hold of it by whatever means, can perform any actions with the API, subject to the privileges (permissions) and limits associated with the API key (and your own account).
• When actions are performed with your API key (by whoever), the API provider knows that (in logging) that these actions are performed with that API key. It won't know which sentient being is doing that. It could be a cat or a dog.
• An API key is NOT an encryption key. You can't "encrypt" something just by having the API key in your hand.

---

Ways API keys can be taken from a system

• Copied from a disk
  • Defense: protect the computer, protect the disk, protect the operating system, protect the file system
  • Defense in depth: use the OS application security, by creating separate OS accounts for web-facing server applications and non-web-facing server applications, and by limiting access to secret-containing files to those non-web-facing server applications.
• Copied from the memory of a running application
  • Defense: eliminate exploitable vulnerabilities from your application
    • Example: choosing a programming language and runtime that has fewer exploitable vulnerabilities as well as being easier to reason about security.
    • Example: avoid using any modules, libraries, dependencies, or services which are not rated for good security
    • Example: fix as much bugs as you can, and patch third-party modules or libraries or dependencies as soon as patches for vulnerabilities are available.
  • Delegate sensitive responsibility to better-built systems. This is the "OS key store" idea you have heard.
    • Note: this applies to cryptographic keys ONLY. It is NOT applicable to API keys. (Remember: API keys are merely "shared secret"; they can't perform cryptographic operations.)
  • Defense in depth: This is the "Proxy" idea that you have heard.
    • Have two applications running.
    • The first one, which is web-facing, is hardened, in the sense that it is programmed in a secure programming language and runtime environment, and it minimizes the attack surface by minimizing its own share of responsibility.
    • For example, it could handle user authentication and input validation and sanitization, and nothing else. It passes on legitimate and harmless requests and responses to the second application.
    • The second application contains the critical application logic, including the code that uses the API key.
    • This second application is not web-facing, isolated from the network by a firewall that is integrated with your web server's application-level OS.
  • Extra defense in depth: Have two (or more) applications, and put the second application (one which handles the sensitive part of work) on a different computer. Protect the second computer with network-layer firewall.
  • How about Javascript (or untrusted client-side code)? They run on the customer's computer (or, a sophisticated assailant's computer), therefore anything it has access to is considered "theirs". Defense-in-depth is now a requirement: your Javascript code must talk to a C# web service hosted on your computer. That way, the client-side Javascript code doesn't need to know the API key.
    • Alternative: Once your customer has authenticated through, you may be able to ask the API service to create a short-lived "session" for your customer. The "session" is used exactly like your API key, but doesn't involve you leaking your API key to your customer. You promise not to abuse this "session", and the customer is the only other party who has a copy of this "session".
• Intercepted when the API key is transmitted on the network unprotected
  • Defense: encrypt the transmission (example: Transport Layer Security (TLS)) so that only your application and a trusted endpoint (the "Steam" API server) can decrypt it
  • Basic requirement: create, use, and maintain the validity of cryptographic certificates (yours, and the API provider's) that are used for mutual encryption and cryptographic authentication purposes.
• Copied from a computer that has a lot of control over the web-facing server
  • Example: your own (home) workstation, from which you do most of your programming work, including the development of your software which runs on a web-facing server
  • Defense: protect all the computers you own (at home, at workplace) as well as all the computers you have control over (at the web hosting service)

---

Ways API keys can be leaked with a human factor

• Accidentally copied-and-pasted the API key into some place which is not protected or is prone to leaking. For example, accidentally adding it to a source control system and then pushing it to a repository on the internet which is then visible to others
  • Defense: .gitignore
  • Best practices: never put the API key into the application source code. Putting it in a file that is git-ignored is the easiest way to satisfy this best practice (in combination with git-ignore).
  • Note that, though, if there is reason to commit app.config (or a general application config file) into the source code repository, then the API key shouldn't go there.
• You memorized the API key, and then telling it to someone else
  • Defense: Don't do it unless you trust that person a lot
• Writing down the API key, and the piece of paper was seen, copied, or taken by someone else
  • Defense: Don't do it. Use a password manager. (This assumes your own computer is reasonably secured.)
• You typed in the API key, and someone else looked over your keystrokes, or your keystrokes gets logged on a keylogger
  • Defense: Avoid doing it too often. Use a password manager to reduce the number of times you have to recite and type it.
  • Defense: Key rotation. Set expiration dates for API keys, and replace with new ones before the old one expires. (This is the catch-all defense for many other inconceivable ways of key leak.)

---

Ways API keys can be masqueraded without literally being taken

• Random guessing.
  • Defense: make API keys long and random enough so that a "random guesser" has a very low probability of finding a usable one. This is the API provider's responsibility, not yours.

---

Ways to limit damage when an API key is stolen

• Limit the privileges (permissions, access rights) that can be performed through the API key.
• Key rotation. Set expiration dates for API keys, and replace with new ones before the old one expires.
• Collect, protect, and scrutinize logs (records) to identify intrusions (both attempted and succeeded) as soon as possible, so that corrective actions can be taken sooner.

---

and there's more ...