9 Replies Latest reply on Feb 12, 2013 6:38 AM by Mike_Mitchell

    Scripted Security Challenge!


      I am currently in the process of changing one of our solutions to the 'seperation model' with two seperate files for the interface and the data.


      Ideally I would like to keep their existing FileMaker user accounts, without duplicating them in both files.


      I have come up with the following solution (in the attached Archive.zip) where you log in to your user account in inferface.fmp12 ( Admin / password )


      I have set the Open File user account on data.fmp12 to a user account called 'Data Entry' so that the user is not asked for another set of user details when they login - obviously this presents a security risk should somebody try to open the file directly. The file is kept on a server which isn't publicly accesible, but I feel it is best to implement some level of security over the data anyway. So to stop the automatic login if the file is opened manually, rather than as a data source for the interface, the is an onFirstWindowOpen script trigger that forces you to relogin.


      I have created a layout called 'SECRET-WORD' - please could you download Archive.zip and tell me the secret word if you can get to that layout (in data.fmp12), thus proving there is a security problem with the file... (and an explanation of the loophole!)


      While browsing for similar threads before posting this, somebody else suggested automatic login to the dummy interface and then storing all the user accounts in the data file... Which I think would be more secure... Layout viewing permissions would likely be a problem, but the security would be around the actual data. (However obviously if the interface blocked access to any layout which would allow the user to edit the data, I think this would have the same effect, unless somebody broke into the data file directly)

        • 1. Re: Scripted Security Challenge!

          James -


          On your data file, wouldn't it be easier just to disallow direct opening over the network? Just check the "Don't display in Open Remote File dialog" checkbox in Sharing, and users won't be able to see it to open it directly. They'll only be able to get to it via the interface file.


          Here's the way I would do this (and have):


          Turn off the automatic login on the data file. Instead, use an automatic login to the interface file, which then calls the data file. That causes the user to enter credentials. Then, the data file calls back to the interface file to re-login with the correct level of privileges. That way, you can store all the accounts in the data file only, and just have accounts for each privilege set in the interface file.


          This approach means you can easily swap out the interface file without ever having to worry about munging up anyone's accounts.


          Hope that makes sense.



          • 2. Re: Scripted Security Challenge!

            hmm.  james... what's that you smell?  coming from the kitchen?  could it be... a pork product?  of some kind...? 

            • 4. Re: Scripted Security Challenge!

              ... and more importantly:


              * How long did it take? (I would like to think constant work, since October haha) ... but I'm guessing a lot less than that!

              * How?

              • 5. Re: Scripted Security Challenge!

                james, i'm really sorry to say this, but i just happened upon this site tonight.  i'm looking around to see what people have done with user management under the separation model --without external authentication.  yadda-yadda.  anyway, umm... well... maybe twenty minutes...?    i created a dummy file, added a  table and duplicated fields in it ("Copy1", "Copy2", "Copy3", etc.), then copy & pasted multiple copies of the data file.  also created and duplicated a script that  when called initiates a custom dialogue displaying the name of the script and whatever parameters are passed to it. duplicated that script a bunch of times ("script Copy1", 2, 3, etc), gave my dummy file the same name as your data file's, opened your ui file, watched the results, put your data file back, did the same thing in reverse, created something to trigger whatever scripts you were using.  all that, with a little help from admin / password and use of the script debugger and a little [command-period] when your data file was hiding in the "show window" menu.  anyway, there it was.  hope this exposition is sitting okay with you. it's meant only to help. i feel awful for bursting your bubble  .  anyway, good luck and i won't tell anyone if you won't~

                • 6. Re: Scripted Security Challenge!

                  Don't feel bad - that's why I posted it up here. I didn't go down this route in the end, and now I'm glad I didn't!


                  Hope you enjoyed the challenge!

                  • 7. Re: Scripted Security Challenge!


                    To be totally honest, the strongest security is to prevent access to the file.  ANY file, someone has physical access to can be hacked/cracked.  There are things you can do to make it not as easy, however, your best security starts with preventing access to the physical file.


                    Not to mention, it would have been more difficult if the account Admin was set with such an easy password.

                    • 8. Re: Scripted Security Challenge!

                      Hi Mike,


                      I understand part when you login into interface file and when interface file calls data file. Data file prompts you with credentials window, you enter credentials. The part that I'm not quite sure how it works, is when "the data file calls back to the interface file to re-login with the correct level of privileges." Isn't interface file already opened with minimum privileges at that moment? If you have to re-login into interface file, don't you have to provide your credentials again?


                      I'd appreciate your answer.

                      • 9. Re: Scripted Security Challenge!

                        No, you don't. You use a script that does a relogin with specified credentials. In your data file, you pass whatever credentials you want to use back to the interface file. Use those in the relogin script step. See below (the example uses variables, but you can use global fields or just hard-code it if you want).