I'm working on a project similar-ish to a budgeting app like mint or ynab. I'll be using the Plaid api, which abstracts away account/routing numbers, etc. Thus, what I'll have access to, and be trying to store, would be the account name, balance, type, and transactional data (amount, location, name, type, date, category).

I'd also like to store the user's name and email. I was thinking that if I encrypted the name and email, that that would be "enough", but I'm still a little uneasy about that. So, here are my questions:

  • How much should I encrypt?
  • What's the best way to encrypt it? Only the email really needs to be reversible by me.
  • What's the best storage medium? I was going to just use postgres, but there might be a better way to store this data.

Thanks in advance for any tips, tricks, references, whatever!

1 Answer 1


First of all, this depends on the country you are in and its laws. The best practice is to encrypt all your user data since you are handling financial data.

Just to avoid confusion about data encryption, there are generally two things to deal with, as described below. The reason I bring this up is that in my experience people tell me as a security consultant that "the database is encrypted".

However, by asking a few more questions, it turns out that the data in the database itself is not encrypted but the disks the database is running on.

1. Disk Encryption

This type of encryption protects your data from being stolen if one of more physical machines are in rest (turned off and stolen perhaps)

2. Database Encryption

This type of encryption protects your data in the database itself. For example, if an attacker is able to (partially) dump your database, the records are encrypted and is basically useless to the attacker.

The only challenge here is, where do you store the encryption key. This key should never be on the same disk (e.g. in a configuration file) of either the application server and database server.

In order to read the encryption key, a 'vault' mechanism is recommended. Google "encryption key vault" should lead to several solutions that you could implement.

How much should I encrypt?

In my opinion, financial data itself should definitely be encryption but this also depends on regulations and company policy. I have been in companies that use the following policy:

"Every record that can be used to identify a person is considered sensitive data"

Examples are: Social Security Numbers, bank account numbers etc.

What's the best way to encrypt it?

In my experience, most of the time, symmetric key encryption is used.

What's the best storage medium?

Most open source databases support column encryption, so does Postgres.

  • Thanks @jeroen! Luckily I'm hosting my db on something like google cloud platform, so disk encryption is already taken care of for me (from what I've seen). I was already toying with the idea of setting up a vault (hashicorp) instance separate from the main app, so I guess I'll do that. In your mind, should each user get their own key, or should there be a single one? And just to clarify, when you say all financial data, is that everything related to a transaction, or just the personally identifiable bits like account name, amount, etc? I won't ever have account numbers or SSNs. Thanks!
    – Mike
    Mar 22, 2018 at 2:33
  • Hi @Mike, I actually sat down with several people from Hashicorp for the enterprise edition and I can tell you that they really thought it through. With all financial data I mean transactions and balance for example. While you are at it, it might be a good idea to consider encrypting more than just that (personal identifiable information)
    – Jeroen
    Mar 22, 2018 at 7:56

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.