11 Replies Latest reply on Oct 9, 2012 9:39 PM by taylorsharpe

    Security Improvements


      I know we just got a file format change and might not see any changes to security for a while but it sure would be nice to see security get some attention seems like it might be a over a decade that we'll have the same security features. Hopefully this will be considered and some attention give to new features when the next FileMaker format comes around.




      Allow calculations to determine field level edits

      Add the table context of the calculation to the DDR for view, edit and delete calculations - currently this is missing and should be included. Otherwise don't allow users to select the context they want those calculations to be calculated from.


      In the meantime one thing I would love to see. A feature available in InspectorPro 4. That when you are selecting fields, layouts scripts, or value lists that there is a popup selector at the top that allows you to select the privilege set to see what the access levels are for the item you are about to select. This way you can quickly check security without having to exit the dialog and come back.


      Might be too crazy to edit security in place - just a thought.

        • 1. Re: Security Improvements

          How about login access control on FileMaker Server to prevent brute force password attacks? Right now a user could keep trying passwords all day, and FileMaker Server would keep responding. It seems like it would be useful to have an FM Server setting to shut down access for x hours after x login attempts. The admin to determine  what 'x' was based on the value of their data.

          • 2. Re: Security Improvements

            Hey Vince


            I strongly support your wish for a way to calculate access/no access on field level.

            So far, this feature had to be implemented by hand and was VERY time consuming and complicated.


            This would be a real improvement during the development of more complicated solutions containing sensitive data.

            • 3. Re: Security Improvements

              Instead of a calculation, how about allowing complete security tables that developers can use in FileMaker solutions? Then you could query them, create relationships to them, see what kind of access every account has to a single object in one glance, edit security to an object across several privilege sets, etc.

              • 4. Re: Security Improvements

                Beautifl - I really like it

                • 5. Re: Security Improvements

                  Great suggestion, but FileMaker has addressed this by giving you the option to use Active Directory (or Open Directory) to provide more sophisticated security requirements.  Not only can you control how many attempts and the delays between attempts, but you can have full control of password requirements (many enterprise systems need more requirements than FileMaker provides natively) and you can do this with Active Directory.  Plus, as a developer, pushing the User ID and password resetting requirements to some help desk IT people handling IT gets those duties off my FileMaker development desk.  I dislike having to reset people's passwords and just assume someone else do that. 

                  • 6. Re: Security Improvements

                    This is part of my hope for all kinds of Database Design Tables: https://fmdev.filemaker.com/thread/67325

                    • 7. Re: Security Improvements

                      External Authentication does not fully address brute force password attacks.

                      Databases still have to have local accounts, and these accounts are still subject to brute force password attacks.

                      • 8. Re: Security Improvements

                        Many small businesses set up FileMaker Server directly facing the Internet without employing Open Directory or Active Directory as an intermediary. One of the selling features of FileMaker is that it doesn't require an IT department to run it and so people set it up the most straightforward way.


                        I was also thinking about internal attacks — someone in shipping wanting to get access to the payroll database etc. There are three components to figure out in a hack and attacking from inside the network gives the would be hacker two out of three: the server address and a list of staff user names. All they need figure out is the password. I have played around with building a system that would allow a would be hacker to attempt multiple passwords. A bit of this, a bit of that, some third party keyboard controller software and you have a working system.


                        I still believe a timeout control after X unsuccessful attempts should be built into FileMaker Server, without relying on OD or AD.

                        • 9. Re: Security Improvements

                          Eric:  External Authentication just means something else is running the authentication than FileMaker.  And, YES, external authentication services can be configured to handle brute force attacks by quite a few different techniques.  But don't believe me, just go to NIST 800-53 controls for a secure database in a federal security plan.  But I agree that FileMaker itself does not have a service the monitors for brute force or has controls to address these types of attacks. 


                          Doug Alder:  Yes, some additional security controls would be nice for FileMaker for not only things like frequency of attempts, but delay times between attempts extending between each attempt.  Also, white and black listing IPs would be good and there are many other examples of things you can do with AD or OD that would be nice in FileMaker.  Security is one of those things that always is needing increasing and FileMaker has fortunately been very secure with almost no known successfull attacks without insider User ID/password info.  But you can't stand still on security and need to always be improving it.  Anyone remember the good ole FileMaker days when all you had was a password and no User ID?  Things sure have changed. 

                          • 10. Re: Security Improvements

                            We believe you, Taylor, but none of those methods addresses the necesary FileMaker accounts in every file.

                            • 11. Re: Security Improvements

                              Eric, that is true assuming you are using FileMaker accounts instead of Active Directory to control security.  FileMaker provides you the tools to move into serious enterprise level authentications and they acknowledge that their default FileMaker tool is not a complete enterprise solution.  If you need serious security and authentication, you'll need to move past the default FileMaker security and use the tools FileMaker has provided for an enterprise level system and that is to authenticate using Active Directory (or Open Directory).  Once you'll learn those tools, you'll realize that FileMaker has opened up very in depth security controls to you as a Developer.  In the Active Directory end of things, you do not use FileMaker accounts to authenticate, you use Active Directory groups and FileMaker does not authenticate to individual users, but instead Active Directory Groups.  I don't think FileMaker has any intention of becoming a substitute tool for Active Directory and that is why they provide it as a tool for you to use if you need more in depth security controls than you can handle with standard FileMaker security accounts.