2

Is sending an encrypted connection string as an API Key through headers a good idea?

Someone once told me, storing API Keys in a DB is a bad thing to do but I can't seem to figure out how, when in the end all an attacker has to do is use fiddler to check the headers you are sending in requests for the API Key.

The reason I want to store API Keys in a DB is because I want to create a portal so users can view API keys for specific services of my microservice application. Thus making the API Key readable in plaintext.

  • I can't tell what your exact question is, or if it's related to system security. Maybe one of the programming-oriented stackexchange sites would be a better fit? – Ethan Kaminski Oct 14 '18 at 14:18
  • THAT question is clearly security-related, yep. If you ask that specific thing, I think it's on-topic and worthwhile :). Could you either edit this question to focus on that, or else ask a new question (with the "Ask Question" button, rather than via comments)? – Ethan Kaminski Oct 14 '18 at 14:30
  • Okay I've updated the question to be more security specific. This question actually baffles me @EthanKaminski – KTOV Oct 14 '18 at 14:33
0

For most intents and purposes, its good to think of an API Key as a username/password combination. The reason it's generally frowned upon to store API keys in the database in a reversible format is because if your database gets breached, it's possible for an attacker to gain access to all of the API keys which are stored in the application, and impersonate other users.

Showing users their API keys in plain text is essentially the same as showing them their passwords in plain text. A more secure alternative might be just allowing them to reset their API keys, and not showing them what the original key was.

  • Agreed. This is why most services like AWS, GitHub etc, will only let you see your API key once (when the key is generated) and never after that. You can always invalidate old keys and re-generate new keys, but never will you be able to see the cleartext key again. – keithRozario Apr 14 at 13:46
  • I don't entirely agree. API keys are not as sensitive as passwords. It is certainly true that someone who manages to steal keys out of the database will be able to login as the user. However, that doesn't stop plenty of people from storing, say, cookie information in a database. – Conor Mancone Sep 29 at 13:35
  • The reason we use one way hashing for passwords in databases is not strictly to stop an attacker from finding the password and logging in (although that is a factor). The main reason we hash passwords is to protect the actual password in the event of a breach because so many users reuse passwords. This is not an issue with API keys. So while a stolen API key will allow an attacker in, a stolen password will allow the attacker in, and also allow them to access Facebook, email, etc for the user. Passwords are much more sensitive than API keys. – Conor Mancone Sep 29 at 13:38

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.