2

I'm building a REST application to store credentials -- GitHub keys and other sensitive data (which may be uploaded by web app user). I'm looking for an optimal way to secure the data but I'm lost at how to lower the security risk in case the database/web application server is compromised.

Currently I'm looking at the following solution:

  • Encrypted credentials are stored in the application database.

  • Encryption keys for the credentials are stored in a separate database behind a firewall.

  • This, as I look at it, should reduce the risk if the application database is compromised.

Database is PostgreSQL and the server is likely to be Apache2+wsgi.

Does this architecture make sense? Is it redundant? What can be improved as to the storage of the encryption keys? What tools would you recommend for this use case? Thanks in advance!

Improve this question
2
  • I have answered a similar question yesterday, maybe you want to have a look security.stackexchange.com/questions/136031/…
    – kaidentity
    Commented Oct 7, 2016 at 8:30
  • When you cannot trust someone who would breach into your server you cannot trust yourself. Perhaps you should implement zero-knowledge-storage. Thus that noone (except the user who uploaded the data and has the master password) can use this data in any way.
    – BlueWizard
    Commented Oct 8, 2016 at 10:08

1 Answer 1

Reset to default
1

The key to answering this question lies in thinking about what access your main web application has and what could happen if an attacker were able to re-program it to do whatever they like.

This thought experiment quickly shows the only way to completely prevent the sensitive data being leaked in this scenario is for the web application to never see it, for example by encrypting it on the client with a key known only by the client. This approach is often impractical for web applications. However it is used for some applications such as cloud backups.

However, all is not lost. One can still dramatically reduce the risks of a bulk loss of all of the sensitive data in the system in a couple of ways.

1. Store the encrypted data, but do not store the keys.

In the event of the server being compromised, the attacker only gets the encrypted data. In normal operation the key can be supplied by the user - for example as their password. This has the disadvantage that if a user loses their password, they also lose their data.

2. Place the sensitive data (or keys) on a separate server, behind a firewall accessible only via a restrictive API.

The key to this approach is to design the restrictive API such that if an attacker gains access to call it by compromising the main web application, they are limited in what they can retrieve. There are many ways to achieve this, but the basic ideas are as for any service. Here are some of the things to consider if implementing such an API:

  • Require authentication (as the relevant end-user)
  • Don't provide bulk export APIs
  • Keep the API simple to reduce the risk of programming errors
  • Rate limit requests
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .