11 Replies Latest reply on Dec 15, 2013 2:28 PM by gdurniak

    FM 13: Is there still a need for field-level encryption plugins?

    Jeremiah_Hammond

      Is there still a need for field-level encryption plugins now that we can encrypt an entire .fmp12 file in FileMaker 13?

       

      Sky Dancer Studios, the makers of the Blowfish and Windows AES plugins, have explicitly deemed their plugins useless with the release of 13.

       

       

      NOTE: With the new FileMaker 13 Pro Advanced, you no longer need to use plugins for encryption! These plugins are still provided here for users of previous versions of FileMaker.

       

      Part of me feels there's still a need for field-level encryption beyond the file-level encryption, but I'm unsure at this point. I'd love feedback on how to think through this problem. Is file-level encryption enough?

        • 1. Re: FM 13: Is there still a need for encryption plugins?
          RonSmithMD

          I think that there is definitely a need for an encryption plugin. I use Troi encryptor to place an encrypted text file onto my PediKey which contains information specific to the patient's encrypted PDF on that device.

           

          Ron

          • 2. Re: FM 13: Is there still a need for encryption plugins?
            Jeremiah_Hammond

            RonSmithMD,

             

            I'm talking specifically about field-level encryption, not text-file encryption (my original post was a bit unclear about this; I went ahead and edited it accordingly. Sorry about that!).

             

            FileMaker 13 certainly doesn't eliminate the need for encrypting text files on a file system. I'm wondering if there are valid scenarios where you still need to encrypt a field in the database, even when the .fmp12 file is encrypted.

            • 3. Re: FM 13: Is there still a need for field-level encryption plugins?
              Malcolm

              Is there still a need for encryption plugins in FileMaker 13 now that we can encrypt an entire database file?

               

              Part of me feels there's still a need for field-level encryption beyond the database-wide encryption, but I'm unsure at this point.

               

              What would the point be, of encrypting at the field level? Would you do this because you didn’t trust the database level encryption?

               

              If the encryption could be broken at the database level what would prevent the field level encryption being broken?

               

              If you want to encrypt the data at the field level because you don’t want some users to have access then you are better off using the account privilege settings to control this.

               

               

              Malcolm

              • 4. Re: FM 13: Is there still a need for field-level encryption plugins?
                monkeybreadsoftware

                There is still a need for encryption. Especially for import/export.

                Or for storing data in FileMaker and still have the data not there in clear text if someone has access to the database.

                • 5. Re: FM 13: Is there still a need for field-level encryption plugins?
                  RonSmithMD

                  Well sure. Why would you want credit card information in a field so that it could be read freely if the whole file were stolen? The whole thing might be encrypted, but if you have the password then the credit card information could be visualized unless you stored it encrypted within the field.

                   

                  Ron

                  • 6. Re: FM 13: Is there still a need for field-level encryption plugins?
                    wimdecorte

                    Malcolm wrote:

                     

                     

                    What would the point be, of encrypting at the field level? Would you do this because you didn’t trust the database level encryption?

                     

                    The new feature is about "encryption AT REST", meaning that if the data is not used, it is encrypted.  However, when the user requests the data, it is decrypted and sent over.  At that point it is decrypted completely (all fields).  We already had "encryption IN TRANSIT" through the SSL option in FMS.

                    What we don't have is the ability to leave certain fields encrypted even if the record is being used by the user.  That ability can still be important and is what we'll need plugins for.

                    1 of 1 people found this helpful
                    • 7. Re: FM 13: Is there still a need for field-level encryption plugins?
                      Malcolm

                      >> What would the point be, of encrypting at the field level? Would you do this because you didn’t trust the database level encryption?

                       

                       

                      The new feature is about "encryption AT REST", meaning that if the data is not used, it is encrypted.  However, when the user requests the data, it is decrypted and sent over.  At that point it is decrypted completely (all fields).  We already had "encryption IN TRANSIT" through the SSL option in FMS.

                       

                      What we don't have is the ability to leave certain fields encrypted even if the record is being used by the user.  That ability can still be important and is what we'll need plugins for.

                       

                      I understand that the encryption of the file occurs “at rest.” My question is whether field level encryption is safer than user access privileges for the jobs you envisage?

                       

                      I think that a user who should not see the field data in plain text should not have access to it at all. If the data warrants encryption then I don’t think that the encrypted data should be accessible to the user. The reason being that when a user has the encrypted data they may be able to decode it. So, why give them anything at all? Isn’t it safer to use Account Privileges to deny access to the fields that contain sensitive data?

                       

                      Malcolm

                      • 8. Re: FM 13: Is there still a need for field-level encryption plugins?
                        Order_from_Chaos

                        Malcolm,

                         

                        For what it's worth, I'm with you on this one. If the data warrants encryption, user access privileges is a better way to go to prevent access. Lock the file down and only allow access to those that should be seeing it anyway. Export as others have mentioned is a different matter entirely and still needs encryption protection since it will no longer be protected within FileMaker but the ability to export it should also be limited by user access privileges. Same applies to data import. If users don't have access, it's a non-starter.

                         

                        Brett

                        • 9. Re: FM 13: Is there still a need for field-level encryption plugins?
                          RonSmithMD

                          This is a true real-time statement. There are more ways to hide information from users than encrypting it by field. For example, I have fully integrated credit card processing in my practice management / EHR solution for my office. The staff swipes the card and that data is retained, but the field that they see has the black dots showing with the last four digits of the card. This is a special calculation field where they can never see the full number. That protects both my patients/parents and the staff, each of which are equally critical in my office.

                           

                          I can encrypt the field itself using a plugin. I personally don't think I need to as we have a secure data cage for all the hardware, and a number of other security measures in place as you expect for a physician's office.

                           

                          If I were hosting remotely though, I would feel less secure and the field encryption of that data would be important to me I think. There are password breakers, or at least there have been in the past, for FileMaker databases. Of course the actual password would be contained within the database for any encryption plugin, but you could make it a little challenging at least should the database become exposed like that.

                           

                          In the medical industry, we sling the term HIPPA around a lot. Suffice it to say, that a good rule of thumb is if you have the security technology available to make data as secure as possible, then you should probably do it. That applied in 2000 before FileMaker had the ability to encrypt client-server connections. That was what was available, but of course now all my connections are secure.

                           

                          Companies hosting web sites that transact credit card purchases is another example. I hated the constant nagging from them about web server component version testing where they said I needed to install version x.0002 to replace version x.0001 of something. It seemed that every month something was not satisfactory.

                           

                          But the upgrade scythe of time marches on. Who knows but that we won't be REQUIRED at some point to do field encryption within our databases.

                           

                          Just some thoughts.

                           

                          Ron

                          • 10. Re: FM 13: Is there still a need for field-level encryption plugins?
                            jormond

                            If anyone has access to the hardware, cage or not, it represents an opening for a motivated individual to get at it. If you store only a hash of the card number, or the token from the payment gateway, you eliminate desire of anyone to try getting at the data. So in a case like that, I would say not only is field level encryption necessary, it should be required.

                            RonSmithMD wrote:

                             

                            I can encrypt the field itself using a plugin. I personally don't think I need to as we have a secure data cage for all the hardware, and a number of other security measures in place as you expect for a physician's office.

                            • 11. Re: FM 13: Is there still a need for field-level encryption plugins?
                              gdurniak

                              If "someone has access to the database" or "If anyone has access to the hardware", you might still be screwed

                               

                              It seems the plugin password is often stored in the file too. Once hacked, all is lost, either way

                               

                              greg

                               

                              > if someone has access to the database.