Kirk, Bruno, It seems as if both of you use 1 single key pair to encrypt ALL the secure data. In my situation I am creating a key pair for each user, then encrypting that user's secure data with their own key. this way if one user accidentally, or intensionally gains access to other users secure data they can not actually unencrypted it, as their key will not give them functional access.
I was planning on keeping the keys in the data file... but I can see that might be an issue. Any other ideas on where/how to keep the keys, given the above? None of the data that needs to be secured, is required to be searchable, so that part is not an issue. As far as how far someone would be willing to go to extract the data... that I am not sure. I do not think, but I could be wrong, that I need to procure HSM [whatever that actually is :) ] Thank you for pointing out backups. I had not thought about that portion of the equation. I will need to look into that. I will likely setup a script to compress and PW protect/encrypt the backup. I do have access to an external, encrypted hard... Thanks for the ideas/info it is appreciated! Chip > I've taken the approach of creating a separate table for storing secure > data. Each record has a blob to hold the data. The idea is the sensitive > data is encrypted into a blob and the blob is saved in one of these > records. The record the data belongs to records the secure record id. When > the data is required the blob is copied, uncompressed and unencrypted. > > The benefits are a single procedure to manage any secure data. And a single > place to save it. It's flexible and allows adding new fields as needed. > The detriments are the ones Bruno mentions: the keys are stored in the > code. > > If you store data you want to search on you need to build some sort of > index based on hashes. > > This is especially good for dealing with things like SSNs. > > On Sun, Mar 31, 2019 at 10:50 AM Bruno LEGAY via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > >> >> Hi Chip, >> >> Interesting subject... >> >> You seem to have chosen (if I understand correctly) a good direction in >> your design : encrypt sensitive data (fields) with ENCRYPT BLOB I guess... >> >> This is good, so event when looking at the datafile with an hex editor, a >> clever hacker won't be able to extract data. >> >> It is not easy because the problem is that the data is not searchable, >> sortable... But it is a compromise. >> >> Maybe it would be nice if 4D would have a transparent datafile level >> encrypted/decrypter. A bit like FileVault but at database level... There >> would be a speed penalty, but maybe one could choose field by field which >> data needs to be encrypted... >> >> But then there is always the question of the keys... where do you store >> the keys and how do you protect them ? It would make the job more >> complicated, but not theoretically impossible. >> Also, if you loose your keys, you just crypto locked your data. >> >> The ideal solution is an HSM (piece of tempered proof $$$ hardware to >> store the keys), I have heard of them, but never seen one used. I have not >> idea if it could be used with 4D. >> >> I have written systems where the keys are stored in a function. The >> function returns the base64 key in text... I used these keys to >> protect/encrypt passwords stored in text files. But again a skilled hacker >> could find the keys in your code I guess. >> Definitely better than storing the keys in a plain text file name >> "key.txt" or password in a text file "credentials.txt"... >> >> I rarely encrypt data in our databases (maybe not as critical as your >> case), but one thing I do, is that the backups are compressed and encrypted >> before being sent to another server. >> I use 7z which has an AES 256 encryption option. >> This way, if a backup file is compromised/stolen, the data is "safe". >> >> At the end of the day it is always cost/risk ratio. A compromise between >> the "value" of your data (and therefore the amount of effort a skilled >> hacked would throw at reading your data) against how much your client is >> willing to pay to protect the data... >> >> It is important that you show that you have identified potential risks and >> you have prepared solutions. >> >> Security also require you to be consistent. No point encrypting data if >> your user can export the same data in a file (because he will export the >> data in a text file and then your precious sensitive data will be on the >> loose). >> >> In Europe we have RGPD which is trying to impose guidelines around data >> protection. It will be a long process... Some of it is good sense, some of >> it is not practical (but it makes some specialized lawyers rich along the >> way)... >> >> Bruno LEGAY >> A&C Consulting >> >> ********************************************************************** >> 4D Internet Users Group (4D iNUG) >> Archive: http://lists.4d.com/archives.html >> Options: https://lists.4d.com/mailman/options/4d_tech >> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >> ********************************************************************** > ------------ Hell is other people Jean-Paul Sartre ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
