FileMaker Pro: Security Guidelines

INTRODUCTORY COMMENT: This document, originally titled "FileMaker Pro: Security Concerns", was written in September 2000 as part of the release of FileMaker v5.0 to the MIT Community. I wrote the document primarily to raise awareness among MIT FileMaker users of the security issues that were especially problematic from the point of view of the security gurus at MIT (e.g., Jeff Schiller). These issues included passing data in the clear across the network (a huge vulnerability in an open environment like MIT), and, more especially, the extremely insecure way that passwords were stored and passed by FileMaker.

While I agreed with the security experts about the nature of the problem, I differed with them in emphasis regarding the nature of the solution. Rather than simply rid MIT of inadequately-secured FileMaker usage when discovered (FileMaker usage on campus has historically been kept "under the radar" to avoid just such advice from central IT), I preferred that we also focus heavily on leveraging MIT's institutional weight to lobby FileMaker Inc. to make changes to the product.

In this vein, I raised our security concerns with FileMaker Inc. on numerous occasions (including a very interesting DevCon session in which I learned of FileMaker Inc.'s experience of an earlier MIT run-in...) Eventually, I was invited to participate in the December 2002 "FileMaker Kitchen" in which key members of the FileMaker community could preview what would eventually become FileMaker 7 and give their input.

At this kitchen, I helped spearhead a session specifically dealing with security concerns, and it became clear in that session that FileMaker Inc. was making a major shift in its approach to that area. This was more than just MIT complaining -- clearly, FileMaker Inc. had lost a number of potential customers because central IT at the customer sites had disallowed FileMaker products as "poor IT citizens", notably in the security domain.

My document was revised several times to reflect new versions of FileMaker (the current version is available here), but, sadly, the changes were extremely minor since FileMaker Inc. basically left the security unchanged through version 6.0. As of version 7, the situation is entirely changed. The sections marked "COMMENT" below reflect the version 7 innovations.

--Kevin Cunningham, October 2004

The Issue

FileMaker products allow you to share data over the network and via the Web. It is very important, therefore, that FileMaker developers ensure their solutions meet minimal security requirements for shared data sources at MIT. Please be sure to review the Security Guidelines below carefully, before deploying a FileMaker database at MIT.

Note: If you are looking to create an enterprise-wide solution, or one that requires very high security, FileMaker may not be the most appropriate software for your needs. You might want to explore enterprise-level database management solutions (e.g., Oracle, for which MIT has a site license).

COMMENT: The above statement is still true, but the definitions of "enterprise-wide solution" and "very high security" must be taken more stringently. In a way that earlier versions were not, FileMaker 7 is a reasonable player in medium-size systems, and standard security needs (encrypted traffic, key-based passwords, etc.) are within FileMaker's realm now. By the way, it is not clear that Oracle is the only alternative anymore -- MIT IS&T is currently (Fall 2004) exploring what products to recommend for medium-size database solutions that meet security and IT guidelines.

Although FileMaker software is supported and even recommended for a variety of purposes at MIT, many FileMaker sites on campus make little or no provisions to safeguard the data they store. Partly this is a limitation in the software (currently, FileMaker does not meet MIT's high standards for Kerberos-based authentication or encrypted data transmission), but often it is simply a result of neglect or ignorance. FileMaker, Inc. is working to provide a solution, however currently FileMaker provides no real security unless you deliberately put it in.

COMMENT: With version 7, the tools are in place, so most failures of security would now be "the result of neglect or ignorance", as the next section points out.

Example

Take an unfortunately common example: a good number of databases created at MIT do not require passwords.

This is all the more remarkable because often the data being stored is sensitive Institute data (including local department data). Although the initial source of the data may have been highly-protected MIT data, it is not uncommon to find a downloaded copy of this data available on a network-shared FileMaker database with no password.

Apart from being a violation of MIT policy (Institute data -- including locally gathered data -- needs to be protected), it is also poor data management and opens departments and the Institute as a whole to more widespread dangers. Suppose, for instance, that a poorly protected FileMaker database contains password information for other MIT services (e-mail passwords, for instance). By getting into that FileMaker database, a hacker would then have the information needed to hack other MIT services, including personnel records and financial data. Maybe the hacker wouldn't even have to go that far -- maybe the database itself has everything the hacker wants to know.

COMMENT: This type of failure is still entirely possible -- and, as always, entirely avoidable. Furthermore, the policy strictures (avoid sending sensitive data across the network in the clear or storing it in vulnerable local sites) are even more important as hackers' skills increase and more data is stored electronically, nevermind that the policies have more legal weight behind them (e.g., HIPAA for health care data, and other laws for student data).

Securing FileMaker Sites

What can you do to secure your FileMaker sites?

1) Always Require Passwords For Your Databases. Just this step will vastly improve the security of your system against the most common threats. However, adding passwords can be a little harder than it sounds. FileMaker's security schemes are somewhat esoteric. For instance, FileMaker's passwords are not inherently tied to individual users; instead, passwords link up more with "groups" that the database designer can define. For the Web, a separate security system is also available.

The awkwardness of FileMaker's password scheme, or the need to administer a large number of passwords and associated privileges, can lead some database developers to work around FileMaker's system and instead create their own table-based username/password "login" scheme. In general, this can be useful in adding features to a database system -- but it usually does not create any additional security, and may even mask security problems left unresolved. In any case, if you choose to introduce a table-based "login system" to your solution, do not base this on blank passwords or auto-entered passwords; the database would be too vulnerable to reasonably experienced FileMaker hackers.

COMMENT: The advice to "always use passwords" -- and not to use blank passwords or to "auto-enter" passwords -- is still sound. FileMaker's user/password/privilege scheme, however, has been completely revamped, rendering much of the above discussion obsolete. For example, FileMaker now supports account names and associated passwords, rather than passwords only. This means a separate table-based "login" scheme is unnecessary. (Some solutions may want to maintain more information about a user than just their account name, so a "User" table and logic surrounding it may still be appropriate, but it is now unnecessary and counter-productive to use it for the actual authentication process.) Developers of old FileMaker systems will need to familiarize themselves with the new account/password/privilege scheme in depth to use it effectively. Also, the ability to piggy-back on Active Directory or Open Directory for local domains should not be overlooked (I have not yet explored whether the WIN.MIT.EDU Athena-like domain approach at MIT could be used here...)

2) Be Aware That Shared FileMaker Data is Sent "In the Clear", Unencrypted and Unencoded. If you share sensitive data in your database (and even if you don't share the data), you should consider ways to store data in an encrypted form -- and only let the data be decrypted when it has gotten to its destination. In fact, for certain data (e.g., student information), MIT is required by law not to send the data over the network in the clear.

Useful FileMaker plug-ins to consider for encryption include the Coding plug-in offered by Troi Automatisering, or the Crypto Toolbox plug-in offered by Protolight Software.

For highly sensitive data, you may need to avoid sharing the data over the network altogether. If you still need to share the data, you may decide that FileMaker is simply not the correct product for your needs. Oracle is MIT's site-licensed recommendation, involving a larger resource investment than FileMaker.

COMMENT: FileMaker passwords are now NEVER sent over the network in any form (an encrypted key system is used), and ALL of the server-client data stream can now be SSL-encrypted automatically with a Server setting (this is not the default, though, and client-to-client db-serving does not have this feature). Furthermore, the database itself is stored as Unicode rather than ASCII characters, so the database content and its sent data is not directly readable (e.g., in a text editor like BBEdit). There is now no technological reason to use an encryption plug-in (some business needs may require it for certain fields). And again, the recommendation of Oracle for securing mid-size solutions is probably overkill.

3) Be Aware that FileMaker Passwords Are Not Really Secure; Never Use MIT Kerberos/E-mail Passwords for FileMaker Passwords. To authenticate users in multi-user settings, FileMaker software uses a security scheme developed several years ago, before the potential (now actual) vulnerabilities of the Internet were well understood. For instance, FileMaker's scheme involves sending all the database passwords from the server to the client across the network in order to confirm a user-entered password. (In contrast, many modern security schemes, such as MIT's Kerberos system, are able to authenticate users without ever needing to send any passwords across the network in any form.) FileMaker's scheme makes it possible for hackers to capture the set of passwords as they are sent over the network.

Fortunately, FileMaker's passwords are at least "encoded" -- unlike the field data, the passwords are stored and transmitted in an encrypted form, not "in the clear." Unfortunately, the encryption method used is extremely weak by today's standards. Consequently, FileMaker's passwords are not really secure: sufficiently advanced hackers can potentially tap the line, capture the encoded passwords, then decrypt all the captured passwords. Of course, it isn't easy, but it can be done. Needless to say, MIT's network is constantly being assailed by "sufficently advanced hackers" -- so this is a genuine threat. (It should be noted that FileMaker is not alone in continuing to use inadequate security schemes. Some other software in use at MIT also suffers from this problem. See the Afterword below.)

In any case, FileMaker passwords are much more vulnerable than Kerberos passwords. Since FileMaker's vulnerability is greater than MIT's central services, it's important to retain the integrity of users' Kerberos identities by keeping FileMaker passwords distinct from Kerberos passwords.

COMMENT: See the previous comment. FileMaker passwords are now never sent anywhere in their original form. When initially entered, they are converted to one-way hash values following a standard security algorithm (PKCS #5 PBKDF2), and the result is then stored in the local database file, or sent to the server "obscured by a propritary modification to a standard cryptographic algorithm". Later accesses of the database compare a hash of the newly-entered password with the stored hash, all this encrypted in transit (if needed). As such, FileMaker passwords are now considerably more secure than before. The injunction to not use Kerberos passwords is less valid on purely technical grounds, since no one (not even the owner of the database, or FileMaker Inc. for that matter) can descrypt the passwords now, but it may be a good practice on other grounds.

4) Ensure the Physical Security of Your Databases. Even if you do not share your FileMaker databases (e.g., you always work in single-user mode with a database on your office computer, or you have the databases on a diskette or portable computer), those databases are only as safe as the machine they are on -- especially if they are not protected by passwords. If someone can get to your password-less databases (get into your office, steal your laptop, etc.), they can get to your data.

COMMENT: This point is still true and important -- and easy to overlook. It is a well-understood principle that if a hacker has physical access to a file, s/he can eventually crack it. This is true in a certain sense even of FileMaker with the new password scheme. There is a program on the Internet, for example, that will forcefully replace a password or its hash value in the FileMaker file, effectively giving the database a new master password. It doesn't actually "crack" the passwords per se (the hacker can't find out what the original passwords were), but it overwrites them and gives access to the record data in the file. (by the way, this strategy is by no means specific to FileMaker files -- this is common hacker practice in many domains.) The point is, this can't be done unless the hacker has write ability on the file -- i.e., physical access. So it's very important to protect your databases from physical access by inappropriate people.

5) Be Especially Careful to Consider Security Via the Web. If you serve your databases via the Web, or intend to, be aware that your data is especially vulnerable to inappropriate access. Web servers are designed to give people access to data, not to keep them out, and FileMaker's Web Companion is no different. If you don't take steps to protect your data with password/access protection -- and additional protections -- FileMaker will not hesitate to give your data away to anyone who asks for it.

Even database developers who set up a database appropriately for network sharing (using passwords, etc.) often don't realize that the same database needs extra protection when opened to the Web. For example, a typical mistake is to place the database itself in FileMaker's Web directory along with the HTML interface files -- this allows people to download the database directly. A more elusive point is that FileMaker's Web server has known holes that the standard FileMaker password system does not protect against (especially regarding fields in related databases).

Another important point to realize when designing security for databases served via the Web is that Web users are not limited only to the transactions you specifically design into your Web pages. For example, if you create a link that uses an option like "name=Smith" in the URL to carefully point users to a specific set of records (Smith's data), there's nothing to prevent those users from editing the URL in a browser to say "name=Jones" or "name=Chen" so that they can see data you did not expect them to look at. If you know of this vulnerability, you may decide to use CDML pre-processor tags in your HTML documents to hide some of the details of the selection criteria you are using (i.e., keep it out of the highly visible URL), but savvy users can just peek at the source of your HTML and see what you're doing. (The "name=Jones" example might be addressed by the next point below -- record-level access control -- but the general point is still true: web users can edit the URLs and potentially access different information than you thought they might.)

Using FileMaker in multi-user ("peer-to-peer") mode at least has the advantage of obscurity -- it's not likely that a random hacker will chance across a database they didn't already know existed. Once you begin serving data via the Web, however, the whole world can quickly become aware of your data and can proceed to exploit inadequacies in your security design.

For additional guidelines regarding security when using FileMaker on the web, be sure to read FileMaker Inc.'s white paper on this topic -- FileMaker Pro Web Publishing Security Guidelines and its associated FAQ [Adobe Acrobat required].

COMMENT: While the web service in FileMaker 7 will now submit passwords from the web server to FileMaker server as if it were a client (i.e., encrypted hash, etc.), the initial entry of the password into a web authentication dialog on a client browser is still vulnerable on the network. Fortunately, FileMaker 7 does not have the old limited Web Companion as its web server -- FM7 relies on "real" web servers (Apache or IIS). Therefore, you can turn on SSL encryption and use https for client-host communication. The setup process will still be a little obscure for database developers, who may not be conversant with Apache configuration and web-server certificates, etc. Fortunately, MIT at least has a way to get server certificates easily and for free, while other sites will have to go the commercial route (or risk self-signing) to get SSL going. As for the security risks of changing http form fields at will (the "name=Smith" case above), this is still an issue, but the now-XML-based FileMaker web access scheme has provisions to limit changes to the form values.

6) Consider Using FileMaker's "Record-by-Record Access Privileges" Feature But Understand its Limitations. FileMaker Pro 5.5 allows data access control for individual records. You can now specify calculation formulae to restrict browsing, editing, or deleting individual records, based on the user’s password. For example, an administrator-level password can be given privileges to access the records of all students in every professor's class, while a professor-specific password might limit the user to browsing the student records associated with courses that only that professor teaches. (Fortunately, unlike certain other FileMaker password privilege settings, this feature does carry over to databases published on the Web.)

Be careful implementing record-level access control. For example, it is possible to restrict "browse" access to specific records but leave "delete" access for all records -- you could have a situation where a user can't see the data in a record, but can blow away the whole record. This is not a limitation of the feature: like any powerful tool, it can be misapplied. Developers should take care to understand the implications of what they're doing when implementing record-level access control.

There are also some unexpected behaviors to take into account, not related to security. For example, you might expect that if a user does a Find on some criterion, the found set would exclude any records the user does not have privileges to view. This isn't the case: the record is included -- the data is just not visible. If you did a CurrentFoundCount to produce some statistic in this case, it might be misleading. Developers will need to consider these kinds of oddities in constructing robust solutions where record-level access control is used.

One final point that might help clarify how MIT database developers should look at this new feature: FileMaker calls this feature "Record-Level Security", but in our environment, it might better be thought of as simply "Record-Level Access Control". Although a valuable way of protecting data, access control in itself does not include all the features that the word "security" might imply to a developer here at MIT. Perhaps that distinction will help set expectations appropriately.

COMMENT: As noted earlier, the way access is controlled in FileMaker 7 has been completely revised. Nevertheless, for controlling access to fields, records, layouts, scripts, etc., the elements involved are similar to those referred to here. These former "group" and "password" privleges are now combined into the "Privileges" (and to some extent the "Extended Privileges") feature of FileMaker 7. So you can still specify criteria by which a user can access parts of the file, and in a somewhat familiar way. (I am not sure whether the "unexpected behaviors" persist into version 7.)

The Future

It is possible (though unlikely) that FileMaker Inc. will build enhanced security (e.g., encryption) directly into future versions of the FileMaker software. It is very unlikely that Kerberos-based authentication will ever be part of FileMaker's approach to security. So, currently, we are left to fend for ourselves and piece together approaches to securing our databases using a variety of methods and tools.

It could be that an appropriate long-term solution to many of FileMaker's security limitations (i.e., the password/encryption deficiencies noted in points 1, 2, and 4, above) may involve sharing databases only via the Web using an SSL-supporting Web server. FileMaker 5.x and later versions allow this kind of setup. Data could then be encrypted by the Web server during transmission and users could identify themselves via Web-based certificates. The databases would have to be designed to work with the certificate information being provided by the Web server. Other limitations of FileMaker's built-in security could be addressed using various features of the secure Web server. Even in this scenario, however, database designers will still need to carefully consider the limitations of FileMaker's Web access (point 5 above) and address those concerns as well.

MIT Information Services and Technology is exploring this and other scenarios and will propose recommendations for the MIT community as they are tested and validated.

Whatever the future, it seems that a good deal of work will still be involved in working around the security limitations of FileMaker in the MIT environment.

COMMENT: I am still surprised at just how quickly FileMaker came through with enhanced security. It is still not Kerberos-based, but nevertheless addresses MIT's main concerns about unencrypted data and passwords being sent over the network in the clear. Furthermore, the use of accounts and passwords rather than the old password-only scheme makes for better accountability. (In general, FileMaker Inc.'s entire relation to its developer community seems to have changed enormously for the better since the version 7 development process was initiated several years ago.) The IS&T "scenarios" alluded to above were my investigations (with Tom Thornton et al) of using SSH tunnelling to protect the data stream; these investigations proved viable, but were not followed up after my departure from MIT -- and of course they are unnecessary for FileMaker 7. The pessimistic prediction that FileMaker Inc. would not address these issues and leave us fending for ourselves happily did not come to fruition, partly, I am sure, from MIT's advocacy to FileMaker Inc.

Afterword

FileMaker is not alone in being vulnerable in terms of security. E-mail programs such as Eudora and even MIT's data backup program, Tivoli Storage Manager (TSM), pass their data in the clear. Other data systems on campus have remarkably lax security (physically accessible machines, data stores with no passwords, etc.).

Regardless, it is important that FileMaker developers on campus take steps to make sure that their databases are secure to the extent possible, and to encourage others to do likewise.

COMMENT: Security is an essential requirement of any networked data system in an open environment like MIT. Former versions of FileMaker made assuring high security very difficult, but FileMaker 7 has changed all that. Developers still need to thoughtfully consider their options and take time to plan for security, but the product is now no longer an impediment to introducing real security.