6

I need to store API keys for my users. These keys are extremely valuable as they are used to buy and sell things. Some users won't want to give these keys to anyone, and I'm trying to figure out a better solution than simply storing them in a database.

It would be nice to some keep control of the key with the user. I consider making an open source script that they can deploy on a server and my app call or similar.

Somone suggested it might be possible to configure a proxy to do something without any code, but this is all beyond my expertise.

Does anyone have any other ideas?

edit: for further clarification

My system is a web app. Each user gives my system their api key, which allows the web app to trade on their behalf (buy and sell things). The essence of the system is that under certain automated circumstances the system will want to trade on the user's behalf.

I am considering a manual intervention with 2FA, which will likely be strong enough in my opinion, but is sub-optimal in that the user won't be able to react fast enough all of the time.

I consider creating some light-weight, open source, partner code that the user can deploy on their own server somewhere. The idea being that it can be independently verified as un-malicious and the user can store the keys themself.

I'm not sure if anything is gained by that approach besides a hacker having to find out the location of script, and even then if my server is compromised they can simply send trades using my system to this script in the same way as if everything was on my server.

I guess the idea of a proxy server would be something like the above, but something at a lower level than an app running on the server. I'm afraid I don't have enough server admin knowledge to speculate on how that might work.

iKode
  • 161
  • 1
  • 4
  • 1
    Hi, and welcome to the site. Can you either tell us who mentioned the proxy idea, or remove that bit? I'm struggling to understand what "do something without any code" may refer to since it is so vague. – NH. Aug 27 '18 at 15:58
  • Your question is telling us why the keys need to be protected, but doesn't tell us much about how your system actually works. Storing keys (especially if you need automated access to them) is a hard problem and depends on the nit-picky details of how your system is designed and what / how the keys are used for. Can you [edit](https://security.stackexchange.com/posts/192411/edit) in some technical detail about your system? – Mike Ounsworth Aug 27 '18 at 16:08
  • @NH. I have updated with more info now... – iKode Aug 27 '18 at 17:26
  • @MikeOunsworth I have updated with more info now... – iKode Aug 27 '18 at 17:26
  • Now I'm even more confused. In order to increase security, you want to let users store their api keys on their own device (presumably at a lower security level than you can achieve on your server). But your server still needs to know their key so that it can do actions on their behalf (or be able to call an api that they host which will process the action). So you still have the key on the server, but now have more copies of it floating around the world? – Mike Ounsworth Aug 27 '18 at 18:26
  • @Mike Ounsworth I'm humbly asking questions of security experts, looking for help. I'm trying to discern the best solution while telling you some ideas I've considered. That's all. You make it sound like a dumb idea. The motivation is to give control of the key to the user, and decentralize the target. I take it you think it's a dumb idea? – iKode Aug 27 '18 at 18:31
  • Sorry, I didn't mean to be judgmental. Normally, services like this go in one of two directions: 1) Store their keys on your server and put time / money into defensive security and monitoring tools around that server (up to hiring a security team). 2) Allow them to stand up your software on their server, then they are fully responsible for securing that machine. If your customers are mostly end-users and you think you can do a good job of security, then do 1. If your customers are mostly companies that have good security teams, then do 2. – Mike Ounsworth Aug 27 '18 at 18:35
  • Responding to _"The motivation is to give control of the key to the user and decentralize the target"_ What's the objective of giving control of the key to the user? Is it that the users don't trust your admins? Is it that you think users can do a better job of security than you can? In general, giving end-users control of their own secrets makes for weaker systems, not stronger ones because end-users tend not to be very security-savvy. Maybe your scenario is different, but the term "decentralize the target" seems like you're making the attacker's job easier; more potential weak-links. – Mike Ounsworth Aug 27 '18 at 18:43
  • @MikeOunsworth thank you for your advice, I really appreciate it. The motivation for giving the user control is to remove give us their api key as barrier to signing up to our service. What you are saying makes sense to me, but surely an attacker would have to locate the location of the user's deployment with the api keys? Would any of this be more secure if the user was running an app on their local computer? I'm guessing 'giving end-users control of their own secrets makes for weaker systems' still applies? – iKode Aug 27 '18 at 20:56
  • Good question. You're getting into Risk Modeling where I'm not gonna know enough of the specifics to give you a solid answer. For the threat model where your admins are bad-guy, then decentralization makes sense. For the threat model where the attacker can't do anything bad until they have very last api key, then decentralization makes sense. For the threat model where the attacker wants a specific user's api key, then it depends how you've implemented it. For the threat model where the attacker will take any api key they can get, then assuming your server is reasonably-well secured ... – Mike Ounsworth Aug 27 '18 at 21:21
  • then decentralized is an easier target because some user is bound to lose their device with no screen lock password, or get malware, or post their API key to github or stackoverflow by accident, etc. Decentralized is also more dev work because you need to provide a way for users to revoke their api keys, recover accounts when they lose the key; if you're supporting your client software on multiple OSes, then look at secure storage options available,etc. I feel like you're in some edge-case where my advice is only half-applicable and it's hard without knowing the details of what you're building – Mike Ounsworth Aug 27 '18 at 21:30

1 Answers1

4

Great question, and one that comes up frequently (though always with different nuances, so there's no good general answer). A quick search found some related questions:

In general, you need to decide which use-category your keys fall into, which will tell you what options you have available:

1. Manual access

By this I mean that they key is only needed when there is a human at the keyboard. This scenario is fairly easy to solve: for example you could encrypt the key with a user-entered password. You still need to think about enforcing strong passwords mitigating brute-force attacks, but it's fairly standard; see how SSH password-protects ssh keys to get inspiration.

2. Automated access

If the sensitive keys need to be stored in such a way that they can be used by an automated process with no human at the keyboard, then you're looking at a very difficult problem because of the conflicting requirements that the machine should have access, but an attacker who compromises the machine should not have access.

The standard solutions to this problem include:

  • Attaching a USB smart-card to the server or issuing one to each user.
  • Storing the keys server-side in a secure vault that will use the keys on the user's behalf, and requires users to authenticate using strong two-factor auth.
  • If applicable, Hardware Security Modules.

Clearly the applicable solution depends a lot on the architecture of your environment.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207