FileMaker Security: Leveling Up a Custom App

I’ve been thinking a lot about FileMaker security. The topic comes up at least two times a day on the community forums. Bets are made, files are cracked in those bets due to the lack of security, and the conversation continues. It is a big topic, and one, I think, doesn’t get as much attention as it should. My attempt to remedy the lack of attention problem is one where I develop a FileMaker security model on an app of mine.

Choose your path

Wise people have schooled me in this part of development: it really is a matter of how much FileMaker security you need. A file of your favorite cheeses might not need so much, but others, like the storing employee HR information, requires ultimate security.

FileMaker security can be thought of as a game of deciding who a person  is and what they can do.

It is kind of like a video game ( a time-sucking past-time for me). I need to level up my character with certain skills or spells or weapons and armor in order to progress through the game. If I don’t care about beating that big bad monster around the corner, I don’t need to attain the proper level or attributes to beat it.

My level needs

So I sat down to think through and plan out the security model for a custom app of mine. The simple file I put together was to test out a mathematical formula for creating a Sudoko puzzle. I wanted to give it out, but I learned it from a book on magic tricks (one of my oft-ignored hobbies). Fearful of my life if I broke the magician’s code and revealed the secret, I held onto the file.

 

I needed to level up my app’s security to prevent some Josh person from breaking in and discovering how the formula works. Here’s what I decided on:

The user should be able to do

• Log in with a username and password
• View layouts and fields
• Run scripts
• Enter data into fields
• Print!

The user should not

• Have access to seeing a script run in debugger.
• Have access to viewing a script in the script workspace (to see how the formula is run or to see how I wrote the script)
• Edit the layout.
• Open manage database.
• Break into it from another file.
• Export the data–I don’t want them to see how my fields are set up and get a clue on the scripting.

That’s top-level security right there!

Leveling up FileMaker Security

I tackled these level-up needs as follows (in the File / Manage Security menu):

Set up a new privilege set

I created a privilege set from scratch just to walk through the controls in this area. You can see the settings here.

A newly-created privilege set has absolutely no access granted. All boxes are not checked, and all the Data Access and Design drop-downs say “none”. That fact is something to remember, and it is a quite opposite of creating a new file, where that action gives full access to everything. So I had to go through each line to make sure I had the correct settings.

For the Records Access, I chose this:

Like the general settings, these start with “no” as the choice. I had to update each one as necessary.

For a moment, let’s review the choices for these settings. You have three: Yes, No, Limited. The first two are easy but the third one requires some thought. We’ll explore this in a later post, but it is a place to set a calculation to determine the access. For example, I could say anyone who’s first name is “Josh” has no access to the records in a table.

I’ve set up a new privilege set. Now I have to work on the accounts and login.

Set up the account and login

I created an account called “user” with the password “sudoku_’user’* and gave it the privilege set created above.

Next, I set up the Admin account to have a password (I won’t tell you what it is).

Finally I removed the ‘auto-login’ feature found in the File Options of the File menu.

*Note: I realize the password above is not very secure, but since many folks will download this file, I didn’t want to have to give a unique account and password to each person 🙂

Pause and Assess

So far my set up has been pretty good. I’ve taken care of both the ‘who is the person logging in’ though the account creation and ‘what she can do’ by setting up the limited privilege set. But now I have to remove “God Mode”.

God Mode – get in from the side

Another step in my leveling up is to remove what I call “God Mode.” In video games, the concept of “God mode” is the ability to get in and do whatever you want using a cheat code. In FileMaker we don’t have a cheat code, but we do have a sort of God mode. I can create a new file, call it “GodMode.fmp12” and I can set up an external reference to the Sudokou.fmp12 file if I can get to that file, whether it is on a machine or on a server.

 

With that reference created, I can get in by adding a table occurrence of Sudokou.fmp12 in GodMode.fmp12. Now I have access to fields, tables. GodMode.fmp12 has access to the scripts, the very scripts, in my case, that perform the ‘magic’ of creating the puzzle. I can write a script to perform “Create Sudoku” in the Sudoku file, debug it and see how it works.

God mode is powerful.

Disabling God Mode

Preventing God from accessing my Sudoku file is easy, but it is a setting a bit buried away in the FileMaker security settings. It is “File Access”.

 

This simply says that GodMode.fmp12 needs full access privileges of Sudoku.fmp12 to access the file.

When GodMode.fmp12 tries to access Sudoku.fmp12, this message pops up:

Failing to enter the Full Access account and password of Sudoku_Security.fmp12 will not allow GodMode to have access to the file. No access means no access to fields or scripts.

Optional: Remove Full Access

A hacker can do a lot of damage if they have Full Access username and password. So we can get rid of it. In FileMaker Pro Advanced, in the Tools / Developer Utilities, there’s an option to remove admin access permanently. That means that once stripped, the file cannot be edited as it previously could. It’s worth doing, but not always necessary. If you keep tight control over your password and don’t write it down on a post-it note and pose for a picture next to the note, you should be fine.

Other Security Measures

A final step in leveling up the security of your app is: Encryption at Rest, or EAR as we developers call it. This feature, again found in the Developer Utilities, actually encrypts the physical file.

EAR requires a user to enter a password to decrypt the file before it can be opened.

Without encryption, a hacker could open the file in a text editor and gain some knowledge possibly about the file. It might be worth trying it out.

My file isn’t encrypted, but when I opened it in a text editor, I couldn’t make heads or tails of it.

 

Security is such an important part of FileMaker development. We’re working with real data and valuable data (okay, even a database of cheeses can be valuable to someone ). So it behooves us to find the right level of security for each and every system. For my file, available below, I had to make sure that you couldn’t get into it, so I took proper steps to ensure that. We should do that for each of our files. WE should level up our file to the best security for our particular needs.

Download the file