How to store api keys

[TGDesigns]

Hey all!

Just looking for some quick advice, the app im working on requires api keys from a 3rd party to work correctly. How do I go about storing them safely in my database?

I cant store them how I would store a password because I need to be able to use them again so how do?

Sorry if this seems obvious, just interested is all. I tried a whole bunch of searching but everything seems swamped with how to safely store passwords!

Cheers,
Greg

 

[adam]

Is this in PHP? Store them in a config file in a PHP file outside the public root.

Lots of options for storing configs but I like an array! Then just require that in files you use the key.

 

[TGDesigns]

Sorry you right I probably should have mentioned its php XD The problem is I will be storing keys on a per user basis so would storing them in a file outside of public root work?

 

[adam]

Sorry you right I probably should have mentioned its php XD The problem is I will be storing keys on a per user basis so would storing them in a file outside of public root work?

Ah, in that case, a database can be a perfectly secure way to store them just like you would any other info. You could encrypt them with a key stored on your file system so you would have some backup security if your database was compromised. You could create an API keys table with a column to link back to user by ID.

Depending on what they’re being used for they could also be encrypted using the users password as a key but of course it would need decrypting each time they’re accessed.

What’s the use case?

 

[TGDesigns]

They are keys for accessing amazons api so are needed semi regularly for pulling in shipment data and submitting reconciliation cases, its an internal app running on a local server so it doesnt need to be fort knox but im using it to learn a little more about security. I already have a config database that is linked to the accounts database via user ID, I was hoping to be able to store them there with some form of encryption.

 

[Gummibeer]

Like @Adam said encrypt them in your database. If it's Laravel they come with an easy to use en/decrypt class.
The super secure way would be something like Key Vault | Microsoft Azure but could be too much and if not done right the same (in)secure like your own DB.
Because your app can decrypt them everyone with the same access like your app can. So you have to secure your app server and put the key file outside the webserver reach and in best case prevent access by Unix privileges. The algorithm used is the second most important thing. Laravel uses the best available by default. AES256 should be used or anyone the is based on it.
Something else could be another DB with a lot more user restrictions to prevent it get dumped in a default DB dump by a malicious person.

 

[Gummibeer]

PS: most times the biggest problem is the team. So the persons with granted access who misuse them.

 

[Gummibeer]

PPS: if that are customer keys you should log EVERY activity on them. Create, read, update, delete. Following GDPR you are required to do so and it's also good to be able to tell the customer who has accessed their key when and why. I would also add something that recommends the customer every X weeks to regenerate the key and invalidate the old one. Or even use a time limited one, like oAuth, in general - if possible.

 

[TGDesigns]

Sorry for the late reply, I'm not currently using larval but just so I'm understanding correctly they should be encrypted and then stored inside the database and the encryption key should be stored outside of public access?

 

[adam]

Sorry for the late reply, I'm not currently using larval but just so I'm understanding correctly they should be encrypted and then stored inside the database and the encryption key should be stored outside of public access?

Seems like your best bet to me! Not sure which encryption library is best I guess that’s another question. 😅

 

[tom]

If you need a high secure facility, you can also have a look at Vault by HashiCorp
That's what I'm using for storing sensitive data provided by users eg. username/password combinations, ssh keys, api keys, access tokens, ...

 

[TGDesigns]

Oh interesting, does that mean I could keep the keys on my server and store only the encryption key over at vault? thus keeping it off server?

 

[tom]

Basically you should separate the Vault from your server and put it on a second server.
Then you'll create credentials (eg. AppRole if you're only doing server to server communication) and policies for the credentials, so every credential can only access the path it's intended to access. Also distinguish between read and write access for your credentials.

In my current project I'm using the Laravel app to write the credentials into Vault and the CI pipeline in the background (without frontend/public access) only reads them. So Laravel has create/update access policies and CI has read(/list) access policies in place to create/read the data.