Re: Securing sensitive data in a 4D data file
Bruno, Thanks for the info. In the mean time, I am going with simple and (functional?) the specific fields that need to be protected are encrypted. While I do need to unencrypt the data for various uses, once encrypted in the database the field is never again un encrypted. When it is needed, it is copied, into a variable, un encrypted, used and thrown away. Chip On Thu, 18 Apr 2019 08:01:17 +, Bruno LEGAY via 4D_Tech wrote: > Hi, > > Native database level encryption is coming !!! > > If you need this, it is probably worth waiting for 4D v17 R5 / v18 ! > I would be silly to re-invent the wheel... > > This is a great feature and a good selling point. Thanks 4D. > > https://blog.4d.com/introduction-to-data-encryption-in-4d/ > > Bruno LEGAY > A Consulting > > >> Le 2 avr. 2019 à 11:14, Bruno LEGAY a écrit : >> >> Hi, >> >> Instead of keychain, which is a good idea but maybe problematic for >> cross platform and backing-up / restoring. Don't get me wrong, I >> like and I trust apple iCloud backups but maybe not a good option >> for your situation. >> >> There is the PKCS12 file format which is made to store private keys >> (a keystore)... The file is a secure (encrypted) key store which can >> be opened with a password. >> >> This way, each user has a keystore password (random generated) and a >> pkcs12 file in a blob, the keystone password is encrypted with a >> master password (or using a custom user password). >> The keystore contains the private key. The public key can always be >> generated from a private key. >> You will have to be sure that the system works when user changes his >> main password, etc.. >> >> openssl can manage PKCS12. >> >> Contact me if you need some help on this (I have done a lot of >> openssl stuff with 4D components). >> >> HTH >> Bruno LEGAY >> A 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 > ** --- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ** 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 **
Re: Securing sensitive data in a 4D data file
Hi, Native database level encryption is coming !!! If you need this, it is probably worth waiting for 4D v17 R5 / v18 ! I would be silly to re-invent the wheel... This is a great feature and a good selling point. Thanks 4D. https://blog.4d.com/introduction-to-data-encryption-in-4d/ Bruno LEGAY A 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 **
Re: Securing sensitive data in a 4D data file
Hi, Native database level encryption is coming !!! If you need this, it is probably worth waiting for 4D v17 R5 / v18 ! I would be silly to re-invent the wheel... This is a great feature and a good selling point. Thanks 4D. https://blog.4d.com/introduction-to-data-encryption-in-4d/ Bruno LEGAY A Consulting > Le 2 avr. 2019 à 11:14, Bruno LEGAY a écrit : > > Hi, > > Instead of keychain, which is a good idea but maybe problematic for cross > platform and backing-up / restoring. Don't get me wrong, I like and I trust > apple iCloud backups but maybe not a good option for your situation. > > There is the PKCS12 file format which is made to store private keys (a > keystore)... The file is a secure (encrypted) key store which can be opened > with a password. > > This way, each user has a keystore password (random generated) and a pkcs12 > file in a blob, the keystone password is encrypted with a master password (or > using a custom user password). > The keystore contains the private key. The public key can always be generated > from a private key. > You will have to be sure that the system works when user changes his main > password, etc.. > > openssl can manage PKCS12. > > Contact me if you need some help on this (I have done a lot of openssl stuff > with 4D components). > > HTH > Bruno LEGAY > A Consulting > > > signature.asc Description: Message signed with OpenPGP using GPGMail ** 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 **
Re: Securing sensitive data in a 4D data file
Hi, Instead of keychain, which is a good idea but maybe problematic for cross platform and backing-up / restoring. Don't get me wrong, I like and I trust apple iCloud backups but maybe not a good option for your situation. There is the PKCS12 file format which is made to store private keys (a keystore)... The file is a secure (encrypted) key store which can be opened with a password. This way, each user has a keystore password (random generated) and a pkcs12 file in a blob, the keystone password is encrypted with a master password (or using a custom user password). The keystore contains the private key. The public key can always be generated from a private key. You will have to be sure that the system works when user changes his main password, etc.. openssl can manage PKCS12. Contact me if you need some help on this (I have done a lot of openssl stuff with 4D components). HTH Bruno LEGAY A 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
No - not going to world tour. > Chip- > > Any chance you are going to World Tour? You might see something of > interest ;-). > > Mike > > Mike Beatty > Objective Systems > ** > 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
Chip- Any chance you are going to World Tour? You might see something of interest ;-). Mike Mike Beatty Objective Systems ** 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
Thinking about this a little bit. (BTW - I am going to use keychain to refer to both platforms equivalent) If the system is running client server - the keys would need to be stored (and retrieved from) the server's keychain, and this is/would be fine, as long as it was insured that keychain was backed up AND recoverable in case of disk or other hardware failure. However, if the system were to be merged with an engine, or simply run in 4D standalone storing the keys in keychain would make the app not portable, and the key pair to unencrypted the data would be tied to a specific machine, and again the issue of recoverability of the keychain data comes into play. Any thoughts? Chip On Mon, 1 Apr 2019 07:04:36 -0600, John DeSoi via 4D_Tech wrote: > On the Mac one option is to script storing the private key in the > Keychain with LAUNCH EXTERNAL PROCESS. Type "man security" Terminal > to see the command line interface options. > > John DeSoi, Ph.D. > > >> On Mar 31, 2019, at 10:54 PM, Chip Scheide via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> 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? > > ** > 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 > ** --- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ** 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
Tom, The 'owner' of the data is indeed the user. if they become incapacitated, or whatever, then there is no loss to anyone else. Chip On Mon, 1 Apr 2019 06:38:35 -0700, Tom Benedict wrote: > Chip, > > Just checking to confirm that the ultimate ‘owner’ of the data is > indeed the individual user and if they are incapacitated or lose > their key that is OK and ’their’ data is inaccessible forever. Or is > there a need for a ‘master’ key? > > Tom Benedict > >> On Mar 31, 2019, at 21:54, Chip Scheide via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> 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? >> >> Chip >> > > --- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ** 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
Chip, Just checking to confirm that the ultimate ‘owner’ of the data is indeed the individual user and if they are incapacitated or lose their key that is OK and ’their’ data is inaccessible forever. Or is there a need for a ‘master’ key? Tom Benedict > On Mar 31, 2019, at 21:54, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > 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? > > Chip > ** 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 **
RE: Securing sensitive data in a 4D data file (Chip Scheide)
Windows has some support of Public Key Infrastructure. Maybe that's useful for storing keys. Some examples using Powershell: To find all relevant Powershell commands: Get-Command | where Source -eq pki To list certificates: Get-ChildItem Cert: List user certificates Get-ChildItem Cert:\CurrentUser\ List certificates of a certain publisher: Get-ChildItem Cert:\CurrentUser -Recurse | where Issuer -like CN=Bundes* More infos: * https://technet.microsoft.com/de-de/library/hh848636(v=wps.630).aspx * https://blogs.technet.microsoft.com/scotts-it-blog/2014/12/30/working-with-certificates-in-powershell/ Regards Lutz ** 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
Nice Idea! I don't think windows has an equivalent to keychain does it? THANKS Chip On Mon, 1 Apr 2019 07:04:36 -0600, John DeSoi via 4D_Tech wrote: > On the Mac one option is to script storing the private key in the > Keychain with LAUNCH EXTERNAL PROCESS. Type "man security" Terminal > to see the command line interface options. > > John DeSoi, Ph.D. > > >> On Mar 31, 2019, at 10:54 PM, Chip Scheide via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> 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? > > ** > 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 > ** --- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ** 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
On the Mac one option is to script storing the private key in the Keychain with LAUNCH EXTERNAL PROCESS. Type "man security" Terminal to see the command line interface options. John DeSoi, Ph.D. > On Mar 31, 2019, at 10:54 PM, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > 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? ** 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
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 Consulting >> >> ** >> 4D Internet Users Group (4D iNUG) >> Archive: http://lists.4d.com/archives.html >> Options:
Re: Securing sensitive data in a 4D data file (Chip Scheide)
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 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 > ** -- Kirk Brooks San Francisco, CA === What can be said, can be said clearly, and what you can’t say, you should shut up about *Wittgenstein and the Computer * ** 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 **
Re: Securing sensitive data in a 4D data file (Chip Scheide)
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 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 **
Securing sensitive data in a 4D data file
I have just finished(?) a project which will contain sensitive information. I have been trying to make sure that the sensitive data is protected. When running the disk the data is on will be encrypted, and I will turn on encrypted data communication between 4D client and server. Data encryption in the 4D system is done with 2048 size key pairs. To this end - to protect the sensitive data, I am asking 3 hypothetical questions regarding nefarious attempts to access the data. 1 - given a **ONLY** a 4D data file, with only the knowledge that the data you want is encrypted inside the data file: How do you go about accessing in some usable manner (decrypting) the encrypted data? 2 - given the datafile in 1 above **AND** a compiled copy of the structure, You do NOT know any (4D password system) user passwords: what do you do in addition to and/or differently from above? 3 - given # 2 above, and you know 1 user level (no access to design or 'user' modes) access password (yours): what do you do in addition to and/or differently from above? for #2 and #3 - When using the system, you are only able to see records belonging to you. - If by some chance you got access to a different user's record(s), under your login, there is code in place to reject viewing the record details, and the information you want (encrypted data) is NOT visible in the record listing(s). Thanks for playing along. I hope I have thought of everything. :) Chip 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 **
