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:[email protected] **********************************************************************
