12 Replies Latest reply on Nov 19, 2015 12:55 PM by Malcolm

    Concept: Custom Login & Auto login Security


      For the following i'm curious of your thoughts and maybe things I overlook:


      I've made a custom login module (design reasons) which I use in the solutions I make. But from the beginning that I use this module security is still in my mind.  I've tested several options to "hack" the database but without success.


      How it works in short:

      - Database is encrypted and File Access is enabled

      - I've made a special login user which automatically logs in after opening the database  (This user only has permission for the login layout and related scripts & tables)

      - In the login layout the application user enters username & password and clicks on the button Login

      - If login succeeds the user is brought to the 'home' layout.


      Now i've added something new. Because it's a custom solution native auto login isn't possible. I've been thinking of several solutions. Starter file on computer where the user enters there credentials and automatically logs in etc.

      But now i've made the following.

      - Database opens

      - Based on the persistent ID an Execute SQL Select query is run on a table where auto logins are registered to find the persistent ID

      - When found it selects the fields of the record Username & Password (encrypted with BaseElements plug-in with AES)

      - The username & password are decrypted in combination with the persistent ID

      - The solution logs in automatically


      I've made this and it works great. But one of my concerns is that the table where all registrations of devices, usernames &passwords  is available for the 'login user'.

      I thought of the following for this problem:

      - Solution opens and Login User 1 automatically logs in (with access to the Auto Login table)

      - OnFirstWindowOpen triggers the script and checks AutoLogin table

      - No success

      - Script automatically logs in with a 2nd Login user which doesn't has access to the auto login table

      - User has to login manually

        • 1. Re: Concept: Custom Login & Auto login Security

          When you say "automatically logs in after opening the database" if this is a scripted process their are ways to "hack" it. The point being that the file is already open and potentially vulnerable until your home grown security is applied. The optimal solution is to check credentials and do not open the file if not authenticated. The FM security system, especially when coupled with active/open directory services, is the optimal situation. Anything scripted and where authentication data is stored in a table is also problematic.


          This is not to say rolling your own security system can't be done or should not be done.. you need to have appropriate expectations of such a system. Nothing is hack proof and the more home grown it is the greater the chance of hacking success.

          • 2. Re: Concept: Custom Login & Auto login Security

            Thanks for your reply!

            'Automatically logs in' is that I mean that the Login user (with only acces to Login layout, scripts, tables) is set in the: File options > Log in using:

            • 3. Re: Concept: Custom Login & Auto login Security

              Jacobi, you would do well to read this thread and the links to security blogs:

              Re: Security and FM



              • 4. Re: Concept: Custom Login & Auto login Security

                Hi Jacobi


                I think you can create your own custom security model (I do it all the time), provided you don't give automatic access to your file to anyone. That's the biggest security hole.


                You must, in my humble opinion, force your users to log into your solution using the standard FileMaker dialog and then you can set fields in order to effectively use Record Level Access and create you own privilege set.

                • 5. Re: Concept: Custom Login & Auto login Security

                  In general:

                  • Anything you do should be based around the built in user account security system.
                  • You should not store passwords for any longer than they are needed to create an account.
                  • Do not use auto-login to let people into the system unless this is a functional requirement, ie, guest access required.
                  • Do not compromise security for aesthetics.


                  Presuming that you are handling a multi-file system this method preserves the full functionality of built-in security.


                  1. Create a database ( or a table ) which stores names, email addresses and roles, e.g., sales, accounts, sales mgr, accounts mgr, etc. Do not include passwords in this information. Use this information to generate user accounts.
                  2. Create scripts to create, edit, disable, enable and delete accounts. These must be copied to all the files in the system.
                  3. Ensure that user access to account management is handled by your scripts. Beware of the "Change Password..." menu you have to control that.
                  4. When user account details change, e.g., change password or privilege set, the changes must be carried through to all the other dbs using scripts.
                  5. All the files in in a multi-file system require user accounts that are in synch. Scripts that modify account settings will have to test for this and be able to handle breakages.
                  6. Do not allow users to modify the data in the account table without effecting change in the system. The users can only see the data stored in the account table. Because they cannot see the user accounts stored internally the account table data and the internal user accounts must always be in synch.
                  • 6. Re: Concept: Custom Login & Auto login Security

                    A slight change to Malcolm's suggestion:


                    1.- Keep user accounts in the "master" file of your solution.

                    2.- Create an internal account to connect your master file with the rest of files on your solution.

                    3.- Control security in the related files using Record Level Access and create global fields or any other calculation to determine if a user has access or not.




                    4.- Keep all your user account control on your master file.


                    In this way you don't need to keep accounts in sync between files.

                    • 7. Re: Concept: Custom Login & Auto login Security

                      I don't recommend this method because it increases the amount of effort

                      required to secure the solution and reduces the scope of the solution.


                      The problem is that the passwords are stored in the scripts. It becomes

                      much harder to maintain security because you may not allow anyone access

                      to the scripts, yet the client may require this. For instance, when

                      clients require a description of the code we provide the DDR. The

                      passwords would be in plain text in the DDR. Some clients want to be

                      able to modify their solution and want script level access. You would

                      need to protect the relevant scripts. Other clients insist on having

                      full access accounts, they would need to have a unique set of passwords

                      for their system.


                      You can take extra precautions to secure against these situations. When

                      you use the built-in security model no extra precautions are required.


                      Your method adds another issue. If a user is able to edit the global

                      fields they can control their privilege level. Let's hope that the

                      global fields are secure. Again, the point is that the developer is

                      now responsible for protecting the global fields - a job that is not

                      necessary using built in security.



                      • 8. Re: Concept: Custom Login & Auto login Security

                        You can take extra precautions to secure against these situations. When

                        you use the built-in security model no extra precautions are required.


                        Absolutely. All the threads on Security, all the documentation, video and external articles and blogs point to NEVER SIDE-STEP FM SECURITY!




                        p.s. watch this video if you don't believe me...

                        DevCon 2015: Security, Inside and Out - Ronnie Rios

                        • 10. Re: Concept: Custom Login & Auto login Security

                          Thanks all for the feedback! I'll digg-in al comments, resources and blogposts


                          So In short for my situation. If I want 'optimal' security use the FM login and not the self made login solution. Even though that the only difference is that in the self made solution the database is already open (with a user that totally don't has any rights. Only login layout, login script etc).


                          I'm still curious how I could hack my own solution.... but that's an other topic. ha ha ha

                          • 11. Re: Concept: Custom Login & Auto login Security

                            I've heard on good authority (in an IRC chat ,so no reference link) that allowing auto-login access to an account whose *only* privilege is a single Re-login script had no threat compared to no allowing auto-login at all.

                            • 12. Re: Concept: Custom Login & Auto login Security

                              You'll find that the easiest way to hack your solution, and therefore to

                              protect your solution, is to look at it from different angles.

                              Ultimately, it's about data security - you are trying to protect the

                              data. You start by doing the sort of sleuthing you do under the

                              christmas tree. Can you figure out what's in the box without taking the

                              wrapper off?


                              Start by looking at the database from the perspective of the different

                              privilege sets in the solution. It's important to know what a user can

                              do with the security settings you have provided them.


                              As a user:

                              Can you print? What can you print?

                              Can you export records? Which records?

                              Can you view all layouts? what level of access?

                              Can you add new layouts?

                              Which tables do you have access to? what level of access?

                              Which fields do you have access to? what level of access?

                              Which scripts do you have access to? what level of access?


                              Answer these questions for each of the privilege sets. They'll all be



                              You also need to answer these questions for each of the extended

                              privilege sets: fmapp, fmxml, fmphp, webDirect, xdbc. You may not have

                              all these turned on but some privilege sets allow users to modify these

                              settings and they could turn them on creating backdoors to the data.