Encrypting private data

Using Django Getting Started
1

Hey all and thanks for your time!

The problem:
I want to encrypt the private data in the database so that only the user and a second password that is not on the server can decrypt it.

Requirement:

  • The user can view, edit and store his personal private data using his password. The data is encrypted on the server so parties with access to the server cannot make use of the data.
  • The financial management however needs to read the data to create the bank transfers that the user authorized. So the user data needs to be also decryptable using a second password that is only known by the financial management.

Ideally neither the users password nor the managements password is ever stored. The people that need access to the private data is only a small subset of the people that have access to the server.

Best case would be:

  • user: can only view and edit the private data when he provides the password each time
  • management: can only create csv bank instructions when he provides the password each time

The principle to encrypt like that should be possible as this scenario is possible with PGP however there may be a way better approach with Django.

Thank you for your time and suggestions!

2

Yes this is possible, if you replace the concept of a “password” with a “private key”. (This is not, strictly speaking done with a password. In the case of PGP and other such solutions, the password merely allows access to that key.)

No, Django does not provide anything like this.

Beware - key management for something like this is a whole industry onto itself. To the extent of my knowledge, the need to regenerate keys from either party requires both parties to receive new keys.

Also, keep in mind that every pair of “User – Financial Management firm (?)” requires a unique set of keys. (It’s not clear from your description here whether “Financial management” is one entity or many.)

I haven’t been in that side of the business for a long time, I don’t have any specific recommendataions - just some thoughts for you to consider when looking at the requirements here.

What are the real and underlying requirements and assertions you’re going to make about the security here?

  • Are you really saying that you-on-the-server will not have any facility to decrypt that data?
  • How will you handle lost passwords / keys?
  • What are your DR / BCP processes going to be?
  • What are your legal / law enforcement responsibilities regarding retrieval of data?

The full answers to these questions are important to help identify what your options are for solutions to this.

For example, proving that you didn’t somehow keep a copy of any generated passwords / encryption keys is effectively impossible. Be careful of what you assert.

Note 1: Don’t bother posting answers to these questions here - this isn’t a topic that can be adequately answered here. Get professional advice. This all seems simple, until it isn’t, and by then you could find yourself in serious legal difficulties.

Note 2: I’m based in the United States, this general information would only apply there. I have no knowledge of the legal frameworks in any other country. I’m also not a lawyer, what I post here does not constitute legal advice.

If you’re handling financial information, you’re going to need to have your lawyers involved - do not rely upon the legal counsel of a firm you’re working with - they are responsible for their client’s interests and not yours. (If you’re an internal employee with this firm, then they are representing you. But if you are under contract with this firm, they’re not. Of course, if you are an employee of this firm, then a lot of these potential issues go away.)

3

Thank you for your elaborate answer!

First of all this is for the membership management of a club (600 members though). So the requirement is not really a legal requirement but rather an ideal one. (right now the data is kept in unencrypted spreadsheets on a nextcloud instance on the same server…). So I guess anything is better than that.

Key vs. Password

Basically a key and a password is pretty much the same - isn’t it? A key is just a password that conforms to a standard format. (of course it is very different for the encryption process and the used algorithms but other than that “its something you know/have” that gets multiplied and mangled to your data.)

but yes in PGP-Speak it would probably be:
user1: user1.privkey and user1.pubkey
user2: user2.privkey and user2.pubkey
accountant: acc.privkey and acc.pubkey

bic_user1: encrypted with user1.pubkey and acc.pubkey
bic_user2: encrypted with user2.pubkey and acc.pubkey

So user1.privkey can decrypt his data, and acc.privkey can decrypt both.

in case of loss of user1.privkey the data of user1 is “rather_lost” and has to be reentered.

in case of loss of acc.privkey basically all data is lost. Better not loose it :wink:

Are you really saying that you-on-the-server will not have any facility to decrypt that data?

yes

How will you handle lost passwords / keys?

delete the encrypted things and enter new ones (better not loose the key of our accountant :wink: )

What are your Desaster Recovery / Between Business Continuity Planning processes going to be?

probably delete and start a new… Should not happen if it does heck it’s a lot of work.

What are your legal / law enforcement responsibilities regarding retrieval of data?

Since our accountant needs access to the data we have access and therefore we have to oblige any valid law enforcement order. So this is by no means a guarantee of anonymity or something but rather a “we do the maximum possible” to protect your data.

4

or you could require each and every user to purchase an HSM dedicated to their own personal use.

</joke> :wink:

5

I know data protection is not sexy… not the same like: “yeay we have redesigned our page now there are flickering flames everywhere… and glitter a lot of glitter…”.

Thats what sells but I don’t want to sell… I want to create a trustworthy platform with changing parties (some trustworthy some less - you never know) having access…