Encrypting sensitive (payment) data about member-database HOT 5 OPEN

Another comment: Saving it encrypted and just letting the flask/django app also know the private key to decrypt it on-the-fly is somewhat pointless. Although this would prevent data-leakage in case only the database is compromised. If the whole app is compromised, where fucked then.

from member-database.

I think your proposal is completely resonable. Do asymmetric encryption, store the encrypted data in the DB and do backups. Then if you need to handle it once a year, get the info from the DB, and do the rest offline. No need the App needs to take care of the SEPA logic, right?

In the old days™️ we used to keep everything on file in an office shelf, and then you were told to hand over a floppy disk to the Volksbank.... so why not keep the private key for decryption on a piece of paper in a drawer. I would argue someone going into a university office to physically get hold of a private key is not one of the 99% of most possible attack vectors we are talking about.

On contrary

It's better to double and triple check our system to make it hard to compromise it...

is far easier to miss.

Semi-false sense of security for us and the users: We need to access the information somehow after all. If e.g. also the private key is compromised, or gets lost, it's no use after all.

As a donor, I expect you to handle the information. My only concern is, that no third party can access it.. Loosing the information is a worst case, thats true. Still printing it out, might not be the worst idea.

So, my baseline is: make it a scenario where a physical attack is the only successful one, and I think we are fine.

just my 2c

from member-database.

@ccauet Thanks for your opinion! And after being nerdsniped for the day and reading into cryptography, I agree with your 2c. Great resource can be found here.

Database-level encryption seems to be not that easy to install and deploq for PostgreSQL (which we use in production). I think now that we want to store sensitive data on the server, we should enable disk-encryption on the server (which may be already activated, I am unsure), which protects the data on the "thief steals disk" level.

For the really sensitive data columns, I would encrypt them. I'd use nacl.public.SealedBox for the actual data encryption and generate the DEK there and save the private key encrypted by nacl.secret.SecretBox with an KEK generated by a password by nacl.utils.randombytes_deterministic.
Then it's only possible to restore the information if you have the password to generate the KEK, which will decrypt the DEK.

This is the ultra-secure path, where even the application itself can't decrypt the data, without the user provided password (rememberd by the pep-board). The less-save-but-common-practice would be to just use a symmetric key to save sensitive data and only provide the symmetric key at the start of the application and save it in RAM while the application is running (using .env files exposes the key to the filesystem, if it is compromised). This means if the application itself or it's memory is compromised, we still have IBAN leaks, but not if the server is compromised.

from member-database.

Sorry for the slow reply, here are my (mostly non-technical) thoughts on the SEPA stuff:
As far as I understand our online banking UI, we are able to manage everything regarding the Lastschriften within the account. The IBANs are stored in our account and the Lastschrift can be scheduled to a frequency of once per year without adding the same IBANs again. It is possible to delete all IBANs manually, but by default, all data is stored anyway.
Since the access to this data is limited to the board (and probably the Volksbank itselt), we decided several years ago that this is not a security issue and we kept it that way. Having frequently used IBANs pre-filled in the UI makes the life of the Finanzreferent/in much easier :)

Now comes my actual point: Do we really need to store the bank account data of our members in the DB? After the online registration, we could send an email with the data to the Finanzrefernt who then has to fill in the data into our online banking account manually. This is not a very high-tech approach, but this would avoid any security issues we might have if we proceed with the double bookkeeping in the DB. The transfer to the online banking account UI has to be done anyway. It might be possible to upload lots of IBANs to the account by uploading a csv or something, but as far as I know our members, we will not have hundreds of IBANs to be added :) So the workload for adding IBANs and scheduling the Lastschriften will be limited.

from member-database.

In princicple I would second your approach @lena-lin

After the online registration, we could send an email with the data to the Finanzrefernt...

This would be the only transfer that may be unsecured. When I hand over sensible data to some entity via a TLS secured website, I would assume this as the minimal level of security that gets applied. So breaking out of this, and send data unencrypted over the Internetz seems inapproriate.

So while trying to keep it very basic, we could:

1. Keep a public key on the server/inside the app
2. Encrypt new banking details with this key
3. Send the encrypted data to the Finanzreferentin by mail who owns the private key to decrypt
4. Keep the last 4 digits of the IBAN unencrypted in the DB, so a user could check the provided information
5. Keep the encrypted data there for some days as a fallback
6. Clean up everything on the server...

What do you think? Simple enough?

from member-database.