1 2 3 Previous Next 98 Replies Latest reply on Nov 4, 2015 12:36 PM by sreese

    Security and FM

    beverly

      In case you didn't see this, Steven Blackwell has a new blog on FM and Security. A must read!

      New Paradigms In FileMaker Platform Security - FileMaker Security Blog - FMForums.com

       

      beverly

        • 1. Re: Security and FM
          nicolai

          Thanks for the tip, Beverly. The blog is amazing!

          • 2. Re: Security and FM
            sreese

            Thanks for the tip! I didn't know this blog existed. I have added it to my reading list.

            • 3. Re: Security and FM
              ibrahim_bittar

              Hi Bev

               

              Lately, everything seems to lead us to a feature request .

               

              I've just read the blog and Steven wisely has said what he has been saying for years. I agree with him in – almost – all of it.

               

              In my opinion, there are two things we need to address:

               

              1.- "Ersatz" security:

               

              I agree that a poorly designed "ersatz" security system can open a big hole in terms of security because it gives the false impression of security when actually there is none. This is even more dangerous than knowingly have no security at all. However, we as developers would agree that we must not give the end user access to the solution's schema.

               

              Now, if we must not give access to the schema, how can we have users created/updated without our interaction as developers?. I certainly do not want every customer calling me to create/update/delete users in their solutions everyday (though it happens anyway).

               

              FileMaker provides some control on user account creation, but that's it. We don't have control on user profile creation. What I call a "user profile" is what FileMaker calls a "privilege set". In order to create a privilege set we must dive into the schema and change things accordingly. Some may state that a well designed solution would never need to have its security changed but experience has proved me the contrary. There is always a new user, who had access to this table but now need access to this another table, etc, etc.

               

              What I'd love to see in a future version of FileMaker is scripted control of privilege sets. This means to be able to set the Create/Read/Update/Delete (AKA C.R.U.D.) permissions of each table via script.

               

              In the mean time, what I came up with was a "user profile" model, where the end user (I call him the system administrator) can create combinations of access levels on each table/module and the assign it to a specific user.

               

              An On-Open script populates global fields with the corresponding access levels and then you have a single privilege set in your solution, with record level access (RLA) based on those globals. No globals = No Access, period.

               

              Screen Shot 2015-10-22 at 10.52.54 AM.png

              When a new user is created, he/she has 12345 as the default password. No password is stored anywhere. If a user forgets his password all he must contact the System Administrator and all he has to do is to delete the account and create it again, this will assign the password 12345 again.

               

              On the other hand, each user can have individual security options:

               

              Screen Shot 2015-10-22 at 11.09.20 AM.png

               

              All those options are loaded at startup and put into globals that are checked when needed.

               

              I've been using this method for years and have not had an issue, may be because I've been lucky..., may be not.

               

              This leads me to the second point.

               

              2.- The inside enemy:

               

              Most of the time, we (developers and customers) are afraid of a "hacker" that, like in the movies, will steal all our information and break our systems, however, there is a much more dangerous enemy: a lazy, sloppy, negligent (and sometimes angry) user.

               

              Over the years, I have seen many many times users that won't change their default password, leave their computers unattended, leave the server available for everybody (even using it as a workstation), sharing their passwords, having everybody with super user access, and a loooong etc.

               

              So, along with all Steven's recommendations, I humbly suggest to add EDUCATION.

               

              We must educate our users/customers to the extent of our possibilities so they understand the risks of not taking security measures seriously.

               

              Sorry for the long post, this is something have been bugging me for years and sounds like a great opportunity to open the discussion.

               

              Best regards

               

              Ibrahim

              • 4. Re: Security and FM
                beverly

                Absolutely, Ibrahim! User Education is key, as is education for db owners who need to be wary of User's Education and endorse it's practice.

                 

                beverly

                • 5. Re: Security and FM
                  wimdecorte

                  ibrahim_bittar wrote:

                   

                   

                  Now, if we must not give access to the schema, how can we have users created/updated without our interaction as developers?. I certainly do not want every customer calling me to create/update/delete users in their solutions everyday (though it happens anyway).

                   

                  In short: External Authentication.  That's exactly what is there for.

                   

                  Barring that (and I see very few scenarios where EA can not be used) then you can script the setup of accounts using the available script steps, or use something like New Millennium's "Security Administrator" tool.

                  • 6. Re: Security and FM
                    jormond

                    I think the point that Stephen makes is valid. In personal experience, I have tested and hacked nearly EVERY ersatz security attempt I've seen, with the exception of one ( primarily being that I didn't have time to toy with it, and another developer broke it first ). And I'm not a top tier, highly motivated hacker.

                     

                    Managing roles is the keep part, since user accounts are easily created/deleted/reformed. I do wish you could assign the roles, or access to certain items, individually in addition to the pre-created roles. Or better yet, allow us to assign multiple privilege sets.

                     

                    But with the use of EA, I've had to do so little work with user accounts. Managers can create users easy enough. If they need a new role defined, I don't want them doing it. So they call me.

                    • 7. Re: Security and FM
                      sreese

                      Josh,

                      I am using a hybrid approach between ersatz and user accounts. I haven't been able to successfully implement AD integration yet. I think its something with the way our AD is setup though, or its possibly our FM server itself. It does some weird stuff also.

                       

                      I have the default login user have very very minimal access, restricted to one layout, table, and script. They then type in their username and password (partial webviewer to obscure the password). It runs the script with FAP, to check the account versus the account table. If they fail a counter is increased per every login attempt that there was actually a password sent. People tend to get a little click happy, so if there was no password it doesn't run the FAP script. When this counter is above a certain number the login script will not allow the user to continue.

                       

                      After that is completed the user account is switched to one of a couple with differing permission sets based on the user who logged in and permissions set inside of a table. When one of the programmers login to the system it puts them in with the highest non-full permissions set available and then prompts them for the admin credentials if they want to login.

                       

                      Each user has highly customized permissions that filter the content they can and cannot access.

                       

                      Since the table that the default user has access to are global fields there isn't really anything they can see, and the files are encrypted at rest, so even if they managed to get the files they wouldn't make it very far.

                       

                      Sure they could try and brute force the attack, but its doubtful they would get very far.

                      • 8. Re: Security and FM
                        wimdecorte

                        sreese wrote:

                         

                        Josh,

                        I am using a hybrid approach between ersatz and user accounts. I haven't been able to successfully implement AD integration yet. I think its something with the way our AD is setup though, or its possibly our FM server itself. It does some weird stuff also.

                         

                        Do expand on that.  EA is typically extremely easy to set up and more often then than not is the concept that "scares" people not the implementation.

                         

                        So what kind of weird things are you seeing, let's get you over the hump...

                        • 9. Re: Security and FM
                          jormond

                          Have you sat through one of Stephen's session showing some of the actual attack vectors? You would be afraid based on the description I'm seeing. Unless you are using the "Relogin" script step to allow FM to manage the authentication.

                           

                          In the end, it's really about your Risk Assessment. Is it worth the risk? That same assessment should happen with any setup or software. I have personally broken into several hybrid approaches. And again, I'm not really that good at it.

                           

                          And the password being entered in the WebViewer is not safe. There are several ways, via plug-ins, and native FM functions to get the value of the WV. This along with a lot of other techniques, usually leave an opening to circumvent the script and access other data.

                           

                          I'm not saying it is impossible to set up something that would be secure, but there are so many moving parts and things to consider, for  98% of FM developers, it is virtually impossible to create a fully secure snap-in security schema.

                          • 10. Re: Security and FM
                            sreese

                            Josh,

                            The point of the web-viewer isn't to secure the password, its a local connection anyway. Its to just keep it from visually being seen. I've never liked that FM doesn't allow us to obscure password fields.

                             

                            Yes I'm using the re-login script step. Its not stored anywhere else. It also doesn't grant access to a full access account. The highest permission stored doesn't allow anything with scripting or layouts.

                             

                            The biggest block I've put in is the default user account has access to nothing anywhere in the solution. I've also added some OS permission changes that keep the user from being able to access the plugins folder to add anything in it.

                             

                            Anyhow, I'm heading out from work for the day. I'll get back to more on my AD problems tomorrow. It won't even check for AD credentials with the settings turned on, but then again our 1 FM server has a ton of weird stuff that happens on it.

                            • 11. Re: Security and FM
                              jormond

                              You are doing what I thought you were doing. Entering a password into a Web Viewer, then verifying that info with something in a table somewhere.

                               

                              The native dialog that appears to Relogin hides the password. If you were using the step that way, there is no need for the Web Viewer, or storing the password in a table in the database.

                               

                              What I'm trying to say is, on numerous occasions, I have ( starting from a low level account ) been able to circumvent the add-on security method and access layouts and data that I should not be authorized to see. I have also from another FM file been able to grab the content of the Web Viewer, while the user was working in it. ( mind you the last time I did this it was back a few versions ago ).

                               

                              Take that as you will, I'm not trying to be a stick in the mud. But security is important to me, because it protects me and clients and their data. I'm not the security expert that others are, but I do know what I have run up against in my 8 years of using FM.

                              • 12. Re: Security and FM
                                sreese

                                Yes, and No. Password type in does not correlate to the login account for the file.

                                 

                                Sent by Outlook<http://taps.io/outlookmobile> for Android

                                • 13. Re: Security and FM
                                  jormond

                                  In the past, that is precisely the setup I've broken into. It can work. But there is another issue with the fact that one can potentially grab the typed info either during the Web Viewer entry, or during the ensuing script.

                                   

                                  I'll go silent on it from here. I don't want to be too irritating on the matter...I know I can be sometimes. Just, please, be careful with that stuff. For your sake, and your users.

                                  • 14. Re: Security and FM
                                    sreese

                                    Josh,

                                    Its not a big deal. I'm alright with the feedback, and I'm all about making it more secure. I talked through the response on the email as I sat at the stop light so I'm sorry if I seemed a bit short. (I had however long the red light was).

                                     

                                    FileMaker was the first programming language I learned, and then I moved on to websites. Security is number one there, but I cannot do everything that I would like to do with PHP & MySQL. FileMaker can be a bit behind the times on security though.

                                     

                                    I honestly wish they would give us a more granular control and better user management tools for multiple file solutions. Ideally I would like to go the AD integration route, but I cannot take the servers offline long enough to figure out why its broken. We are a 24-7 shop. Fortunately we are in the process of ordering some new servers so I will have AD integration working before we migrate the data over. The servers have some other weird FM issues with them as well. The admin console stops responding a lot, it doesn't release resources well, it won't start web-publishing services on its own, nor does PHP work on it.

                                     

                                    So anyhow, my security isn't unbreakable, the minute you think it can't be broken is the minute it can. I just would hope to think that all of the effort hasn't gone to waste in making it at least a shade more difficult.

                                    1 2 3 Previous Next