Open File Security Dialogue Substitution

I recently participated in a French discussion on security (Sécurité - Sécurité - FM Source - Forum FileMaker). In brief: someone asks how to substitute FileMaker's open file security dialogue; he gets some pointers; someone cries danger – avoid at all cost; the discussion veers into danger… what danger? I remember some members of The Soup telling me to avoid the same substitution in the past, so I thought the community could benefit from a discussion on the topic.

First of all, I am of the opinion that there are valid use cases to substitute FileMaker Pro/Go/WebDirect's open file security dialogue. For the newbies reading this, this is the dialogue that asks for your username and password. There are considerations as important as security in business. Some of these shape security decisions. Here are two use cases to illustrate.

The necessity to type a username and password is a deal killer in high throughput environments. It is slow and error-prone. Using the operating system's credential auto-entry option is a no-go when workstations or devices are shared. Think banking: how often do you see staff type in a username and password today? I always see them swiping a card strapped to their wrist. Typing is actually a security risk.

The look and feel of an app is prized in some circles. FileMaker software has a distinctive look for sure. The open file security dialogue screams FileMaker's brand. I don't know about your neck of the woods, however FileMaker's brands are not always well viewed in mine. Reputation is unimportant in some cases: some clients simply want their branding alone to show, especially to their customers.

To customize the process, however, requires the solution to be open, therefore login must already have occurred, therefore at least one of the solution's files must use the auto-login option. This is where security-minded folks cringe. We have just given attackers an effortless way to get into solutions. They can now concentrate on attacking the tables and the remainder of the security model.

Why does the auto-login file option exists in the first place if its usage is such a no-no? Why does the Re-login script step exists too? Could it be that FileMaker thinks there are valid use cases for them? I believe so. Is the FileMaker security model the only security gatekeeper of solutions? Of course not.

Physical and network access can be controlled. VPN or a limitation to WebDirect (no development capability) can limit external access. Device access (shared computers or tablets, typing substitutions such as access cards) can be controlled. Authorized users need not be trusted: solutions can log every one of their activities. All this to say trust can be very limited in a well-secured environment.

The recommendation against substitution was based on a security hole that FileMaker plugged in version 16. There can, of course, be other security holes. I think we should not be too fixated on potential security weaknesses. We otherwise run the risk of halting our use of software altogether out of fear someone will get at our data. I think we should instead mitigate known issues with well-chosen design choices that meet the needs of our customers.

I think we should get in the habit of looking at solutions on a periodic basis to, among things, review their security against newly gained security knowledge instead of sticking to dogma that can either be irrelevant or stop us from using solutions in the first place. We will be more productive and, assuming we are sufficiently diligent and proactive, the security of our data will be well maintained.

Hope this helps. Please add to this discussion. I look forward to your opinion on the subject.

P.S. I avoided getting into how one can create a safe substitution. That is a very different and potentially long discussion. Or article! Let me know if I should write one.


Please do, I for one would love to learn more about this. Thanks