1 2 Previous Next 21 Replies Latest reply on Jan 5, 2015 9:41 AM by jurijn

    Encryption in FM

    jurijn

      Hello,

       

      While I was reading about security topics, I noticed database encryption.

      I have few questions and want to open interesting debate about security concerns.

       

      Should all solutions (DBFM files) that are outside of a production enviroment be encrypted?

      There I think on disks, PCs and laptops, USB and other devices...(backups and development environment)

       

      If I understood right is that encryption just another layer of security before someone can try to access solution with his credentials (pass and account name).

      In FM help it is mentioned that after 5 attempts, the process quits. What means that?

      Is solution than locked to prevent brute force attacks or are these possible.

      Is theresome functinality to prevent brute force attacks on a login layer.

       

      Must this encryption password always be given, when some user accesses a solution (before log in) or work that like unzipping with difference that a user in front of process

      type in an encryption password and the file is then decrypted for repetead accesses (2 phisical files, 1 encrypted and another one new decrypted...).

       

      I miss the ability of setting more advanced password rules in FileMaker PRO (length, type of charachters etc...). Why is this not implemented in FM?

       

      Please share some your opinions and experience.

       

      Regards,
      Jurij


       







        • 1. Re: Encryption in FM
          wimdecorte

          jurijn wrote:

           

          Is solution than locked to prevent brute force attacks or are these possible.

          Is theresome functinality to prevent brute force attacks on a login layer.

           

           

          No, there is no account lockout or anything like that.

          1 of 1 people found this helpful
          • 2. Re: Encryption in FM
            wimdecorte

            jurijn wrote:

             

            Must this encryption password always be given, when some user accesses a solution (before log in)

             


             

            Yes, unless the file is hosted, then the encryption passcode must be set on the server before the file even gets hoted.  But the user will not be asked for it again then.

            • 3. Re: Encryption in FM
              wimdecorte

              jurijn wrote:

               

              I miss the ability of setting more advanced password rules in FileMaker PRO (length, type of charachters etc...). Why is this not implemented in FM?

               

               

              It is implemented.  It's called External Authentication.  You can use all of the OS's features for account complexity, machine restrictions, pw resets,....

              • 4. Re: Encryption in FM
                steveromig

                wimdecorte wrote:

                 

                jurijn wrote:

                 

                I miss the ability of setting more advanced password rules in FileMaker PRO (length, type of charachters etc...). Why is this not implemented in FM?

                 

                 

                It is implemented.  It's called External Authentication.  You can use all of the OS's features for account complexity, machine restrictions, pw resets,....

                 

                Piggybacking on what Win said...

                 

                Although you can set up accounts for external authentication servers in FileMaker Pro, only database files hosted by FileMaker Server can authenticate users against an authentication server. Database files shared by FileMaker Pro won’t authenticate against an authentication server.

                 

                Steve Romig

                FileMaker, Inc.

                • 5. Re: Encryption in FM
                  Stephen Huston

                  Re: password rules in FM

                   

                  You can script any controls you want for restricting password rules, using global fields and patternCount or Filter tests, along with the accounts management script steps. Then you replace the change password menu using custom menus to implement whatever specific requirments you scripted.

                   

                  That process can even be used to control what's allowable for passwords in local files.

                  1 of 1 people found this helpful
                  • 6. Re: Encryption in FM
                    Mike_Mitchell

                    In FM help it is mentioned that after 5 attempts, the process quits. What means that?

                     

                    It means that the user will no longer be prompted for the password after 5 unsuccessful attempts. FileMaker simply stops trying to open the file for that user; he'll have to go through the process of attempting to open the file again.

                    • 7. Re: Encryption in FM
                      jurijn

                      Then i can imagine it is possible to implement some kind of account locking (account deletition) through scripting.
                      Just got that idea.

                      • 8. Re: Encryption in FM
                        jurijn

                        Are anywhere some recommendations regarding backups on external devices (USB, disks, computers,..).
                        How long should encryption password be, recommendations for encryption password?


                        Does people in practice use any adition layer of security?

                        • 9. Re: Encryption in FM
                          wimdecorte

                          Any recommendations in this area would not be specific ot FM but to data in general.

                           

                          Realize that convencience and security will always be at odds.  Which is why the safest database holds not data

                          Your passwords and encyrpion keys should be as long as is practical.  Enforcing something that no user will be able to remember will decrease security not increase it.

                           

                          The most important additional layour of security for backups is prevent physical access to them.

                          • 10. Re: Encryption in FM
                            Stephen Huston

                            There was a time several years ago when most developers thought 8 characters was safe length. Then a hacking process was demonstrated which could bust an 8-character password in a few minutes, and suddenly it seemed to be decided that 12 was the new minimum.

                             

                            That was about 3 or 4 years ago, so it's certainly gotten worse since then.

                             

                            Wim hit the nail with his mention that Security and Convenience are at odds. As long as possible is better, but without being so much of a burden that people start using strings like 1234567890abcde, which will probably crack quickly.

                             

                            Teaching people how to pick and remember long passwords is a challenge, but the idea of phrases with numbers is a good start. Some sample phrases:

                                 "1nce upon a time in the West" or

                                 "I feel like I*m fixing 2 die"

                             

                            Those two 28-character-long phrases each meet some the upper/lower characters/numbers rules, and such phrases, if picked by the user from their own interests, are memorable in spite of length, even being fairly quick to enter via a standard keyboard.

                             

                            [And, No, I've never used either of the phrases posted above myself.]

                            • 11. Re: Encryption in FM
                              Mike_Mitchell

                              I recall some years ago there were three criteria for a "good" password:

                               

                              1) Easy to remember

                              2) Hard to guess

                              3) Hard to crack

                               

                              I'm in agreement with Wim; these three goals are often at odds. Especially when you enforce password security "rules" like "must contain at least one special character, must contain at least one number, must begin with an alpa character, must contain a mix of upper- and lower-case letters, cannot be the same as any of the last 50 passwords you used (and those had to be changed every 2 weeks), cannot contain birthdate, user ID, first name, last name, phase of the moon, color of shirt, eye color, hair color, handedness, or anything else that might be convenient for the user to remember."   

                               

                              In other words, you really have to be careful about your "rules" that enforce criteria 2 and 3, because they often sacrifice criterion 1. When you do that, you wind up with users doing things like writing passwords down underneath their keyboards because they're impossible to remember otherwise. Most breaches do not come from brute force attacks; they come from social engineering or users violating good practices. So many security recommendations I've seen favor pass phrases that are easy to remember, but are long enough to resist brute force attacks (because pass phrase length is the one variable that affects hacking complexity more than any other).

                               

                              FWIW

                               

                              Mike

                              • 12. Re: Encryption in FM
                                DavidJondreau

                                Password Managers can eliminate the need for #1.

                                • 13. Re: Encryption in FM
                                  Mike_Mitchell

                                  Unless someone hacks the password manager.

                                   

                                  Not a big fan of putting all the passwords under the control of a single point of vulnerability. Or failure.

                                   

                                  And yes, I know I'm in the minority.

                                  • 14. Re: Encryption in FM
                                    DavidJondreau

                                    How do you envision someone hacking, say, LastPass? You can be flip about something from ignorance or knowledge, I can't tell where you're coming from.

                                     

                                    No security is 100%, considering the alternatives, a good password manager is clearly the best choice. The LastPass team are professionals, far more knowledgeable about threats than I am. I have found extremely little criticism about LastPass from security blogs. And their interface is really really good.

                                     

                                    I have over 200 passwords stored with LastPass. Now 2/3 are low-value sites, I don't really care if someone hacks my Reddit account. But that leaves 50 or so "high-value" passwords, financial, client database admin passwords, etc. All my passwords are now completely different and random and up to a 24 character mix of letters, numbers, symbols (whatever the site allows). So, no one can hack my Technet password and use it on my bank's website.

                                     

                                    And I need to remember one password, which I change quarterly and no one can ever guess or crack as it too is random and has between 60-140 bits of entropy (lower end is a dictionary attacker knowledgeable about my generation technique, higher end simple brute force).

                                     

                                    I really recommend you take another look. I haven't looked into 1Password or KeePass, but I am 200% satisfied with LastPass.

                                    1 2 Previous Next