Is securing a stand-alone FMP12 solution really that hard?

[truelifeajf]

**edit... I can't edit the title.. but I meant "stand-alone" **

 

Hi all,

 

I've read everything I can in this forum about preventing people from gainging Admin access to your solution and preventing someone giving a copy to someone else... etc, etc.

 

Am I missing something when I say, "it's not that hard" ?

 

For example, I've read a lot about how simple it is to bypass the startup script...

 

But if you've set access to the file to require Admin access, allow user abort is off, and the debugger requires a password... I can't see any way to bypass the startup script.

 

For me I have auto-login of a low-level user account and every single, possible FM function is handled by custom menus and my own scripts.

 

So with everything handled by scripts, allow user abort is always off, no layout or script can be seen in the menus, and there's no "Admin" fields on any accessible layout that someone could modify, and I don't store secure back-end information in global variables, I can only think of someone cracking the Full Access account in fmp12 as a hacking option. But if I remove that account then no-one (excluding thos talented enough to be real 'hackers') is going to be able to see my code / layouts / script / field definitions?

 

So either:

a) I'm reading old posts that were pre-fmp12

 

or

 

I'm missing something

 

or

 

c) I've been doing it for so long that securing a solution is obvious to me, but perhaps not so obvious to newer users... and I should stop being so arrogant!

 

While © is a real possibility, I'm posting this question because given everything I've read I am concerned I've missed a key point somewhere.

 

In terms of ensuring people don't distribute my work, I have a script that "calls home" and I allow it to run for 7 days without an internet connection.

 

Protecting a solution that doesn't "call home" is harder as you need to store (encrypted) license keys linked to expiration dates, etc. I must say though I've never had an issue with it calling home. Others consider it "invasive" or "unethical" yet I've always failed to see why.

 

Anyway, would love to hear from those in the know.

[Fitch]

Who said it was hard? The key is what you said about removing the full access account. FileMaker passwords are hashed, so virtually impossible to crack -- but tools exist that will insert their own password (possibly inserting file corruption as well). But that won't matter if there's no full access account. AFAIK there's no way around that, so you're protected.

 

(PS I fixed your post title.)

[truelifeajf]

Ha, thanks for the title fix

 

Well, a few specific people on this forum are often in the "intellectual property" threads replying to people's concepts about protecting their solutions with answers like, "Ah, but what if somone circumvents that?"... so I kept thinking, "how?", thinking that perhaps I've missed something.

 

But I guess if no one else has anything to say on the matter then I shall relax knowing that I've followed the basic steps to properly secure a FileMaker solution!

[Steven H. Blackwell]

 

So with everything handled by scripts, allow user abort is always off, no layout or script can be seen in the menus, and there's no "Admin" fields on any accessible layout that someone could modify, and I don't store secure back-end information in global variables, I can only think of someone cracking the Full Access account in fmp12 as a hacking option. But if I remove that account then no-one (excluding thos talented enough to be real 'hackers') is going to be able to see my code / layouts / script / field definitions?

 

And that would seem to be the crux of the misunderstandings and misimpressions here.  We talked about this during my presentation at the FIleMaker Product Conference in Chicago last week.

 

To protect your solution, you must think as a Attacker does, not as a Developer does. An attacker wants to bypass or disable security features that developers include in their products to protect intellectual property. Attackers ask what is the controlling mechanism for the protections. Attackers then ask,, “How can I break it? How can I bypass it? How can I manipulate it? How can I turn it off?”

 

When an attack occurs, it is not the Strength of the Attacker that counts.  It's the Strength of the Defender that counts.

 

Most core protections will be governed by the elements set in the Privilege Set attached to the "...low level user account..." that opens the file. This includes layouts, scripts, and fields.

 

As described by the original poster in this thread the scenario here is not sufficient to provide protection against intrusion, unless and until each field, layout, and script is protected by that Privilege Set. If a user then has some sort of relog capability, the same applies to the Privilege Set attached to the new Account.

 

The UI is not part of the security schema. Just because a layout's name does not appear in the layout list or just because the Status Tool Bar is locked does not mean that someone cannot navigate to that layout and see what's on it.  As well, depending on the privileges set onto the specific fields, they may be modifiable, readable, or extractable.

 

Depending on the privileges set onto any given script, the contents of that script may be able to be read.  The script may be told to execute as well, irrespective of whether its name appears in the Scripts menu or not.

 

Depending on the privileges set to specific individual fields, the values in those fields can be read and edited. If any of these fields are part of the controlling mechanism for any "security features" a developer introduces, then unexpected results may occur. This means that the "security features" can be bypassed or ignored or turned off.

 

Depending on the general security architecture of the file, names of scripts, layouts, fields, value lists, etc. can be extracted and used for further intrusions into the files.  Additionally, new records can be created or deleted. Additionally, a number of privileges associated with a particular Privilege Set apply only to the file in which they are defined.  They do not apply to data from that file when those data are accessed by any of several methods from outside that file.  This can include both printing and export of data.

 

As a starter to understanding the relationship between the UI and the data and schema in a file and how you can begin to protect them, you might wish to consult this article:

 

http://www.fmpug.com/resources/security_schema_changes_filemaker_11

 

Kindly overlook the author's many eccentricities. 

 

I hope this clarifies and explains this situation.  There are no 100% guarantees for security protections.  Developers can protect their FIleMaker systems to a high degree.  It is neither easy nor casual to do so.  It requires both an understanding of vulnerabilities a Threat Agent might exploit as well as an appreciation of how those Threat Agents think about their exploits.

 

Steven

[truelifeajf]

Thanks for the extended reply, Steven.

 

I had in fact already read everything you've mentioned in your post. And you speak generally about some really interesting points. But I'm failing to see any specifics.

 

For example, you say:

 

"Just because a layout's name does not appear in the layout list or just because the Status Tool Bar is locked does not mean that someone cannot navigate to that layout..."

 

Can you explain how someone would do that?

 

"Depending on the general security architecture of the file, names of scripts, layouts, fields, value lists, etc. can be extracted and used for further intrusions into the files."

 

How could they be extracted? And if extracted, how would one do "further intrusions" with that information?

 

I'm asking this from the position of having a solution where every possible FileMaker feature that I can find to prevent access to layouts / fields / external data sources / scripts / etc... are locked down.

[Wim Decorte]

 

For me I have auto-login of a low-level user account

 

 

This came up in another thread recently and the analogy that i used there was this one:

 

What do you think is most secure:

- a car with proper locks so you need a key to get in

or

- a car where you can get in without a key but you need something to start the engine

 

Generally, once you are in the car you can find ways to try circumvent not having a key to start the engine.  Also once you are in the car you look like you belong and nobody will bother you.  Whereas when you see someone desperately trying to open a car; that's suspicious.

The equivalent of that in FM is that attempts to log into your file are logged on FMS.  If you forgo that then you have to build your own, which is almost always going to be less secure.

[Fitch]

It seems to me that we're talking about two distinct categories of concerns: one is protecting the ability to use and/or modify the solution, the other is protecting the data. Many of us -- I think including Steven, Wim, and myself -- tend to think more in terms of the latter. (E.g., I work in public health where privacy must be respected and protected.)

 

However, my impression here is that truelifeajf is not as much concerned with that as with getting paid for his product.

[truelifeajf]

Yes, Fitch, I'm talking about security of the back-end "code".

 

I'd really love to hear from Steven or someone explaining how using FileMaker's simple built-in features can't lock down a solution properly.

 

In terms of having auto-login for a user... yes, I agree that would open the DATA up to people who shouldn't be looking at the data. I have my own login system which uses "•" for entering the password, and passwords are stored as hashes using SHA-1.

 

While it's arguable that that's going to be less than secure that Filemaker's password system, it's only less secure if people can get access to your scripts. But if someone has access to your scripts the "login" process isn't breached... the entire solution is.

 

Which is why I'm really interested to see WHAT the theory is when someone suggests things can be circumvented if you set things up as per my original post. I can't find anything on Google about it, any hacking / cracking case studies, etc... but what I do find is people saying that we're misguided if we think that's enough... how is it not enough?

 

I'm happy to think like an attacker would... but can anyone provide any insight into just HOW an attacker might circumvent FileMaker's security?

[Wim Decorte]

There is not a great tradition in the FM community for sharing "white hat" type information.  Forums like these are way to public to do this anyway.  So until FMI embraces the white hat spirit you can plead all you want but nobody is going to share anything here or on any other forum.

 

The vulnerabilities of the hand-crafted security systems have been demonstrated many times over the years in and around devcons and other venues, so seek those out.  Steven Blackwell is widely considered to be the leading expert on all things around FM security so perhaps consult with him.

[truelifeajf]

Ya... I'm getting that impression.

 

All the vulnerabilities I've seen at venues / forums / etc are the obvious vulnerabilities and reading the FileMaker security guide will cover all of those.

 

Based on everything I've heard / read / seen, I am now quite firmly of the opinion that securing FileMaker is basic and no course / ebook / or anything else is required. Until someone can show me how to "think like an attacker" and show me some even basic examples of how they might compromise a system that's "locked down", it's clear to me no such vulnerabilities exist.

 

So, here's my free ebook, outlining what you must do to protect your stand-alone FileMaker solution from people getting access to your code. It's off the top of my head so I'm sure I've missed a couple...

 

 

- Go through each option in the Privilege Set (records, layouts, value lists, scripts) and ensure that the user only has access to what's required

 

- Only the required extended privileges are enabled

 

- Enabled "require full access privileges to use references to this file"

 

- No exporting, printing, or overriding data validation

 

- Have a custom menu (custom script) for every FileMaker command so every copy / paste / new / delete / etc function is handled by my scripts. Replace Field contents is handled by a script so calculated replacements can't be made

 

- The custom menu set only has menu items enabled that are required

 

- No layouts in the layout list

 

- No scripts in the script list

 

- Startup script in data files that set the menu set to someting limited, and a script step to go to a blank layout

 

- Every script has lock toolbars, set error capture to on, allow abort is off

 

- Quick Find disabled on all layouts

 

- Run scripts with full access privileges as "on" only for required scripts

 

- No "silly" things like putting "back-end" fields on user-accessible layouts, or storing passwords in scripts or global variables, etc.

 

- And of course, remove the Full Access account

 

I'm not scheduled to be speaking at any conferences in the near future but feel free to email me if you'd like further assistance on securing your solution!

[Wim Decorte]

 

Based on everything I've heard / read / seen, I am now quite firmly of the opinion that securing FileMaker is basic and no course / ebook / or anything else is required. Until someone can show me how to "think like an attacker" and show me some even basic examples of how they might compromise a system that's "locked down", it's clear to me no such vulnerabilities exist.

 

 

I think that is a very dangerous approach.  You're basically saying "nobody wants to tell me, so it does not exist"... my approach would be to investigate further.  If data/intellectual property protection is important to your solution than that is a vital part of your business strategy.

 

Don't give up so easily.

[truelifeajf]

I'm saying that after 15 years of using FileMaker and never having seen anyone (expert or otherwise) actually indicate to any extent how a hacker might compromise a locked down FileMaker solution... It's quite safe to conclude that securing a soltuion is really, very simple.

 

I'm only re-considering it all now as I'm about to deploy a large solution so I wanted to be sure I was up-to-date. But I've just learned that anyone I talk to has no examples of security concerns beyond that in FileMaker's security guide.

 

Have a read through any post in this forum where people are suggesting ways they might secure their solution, and those poor buggers are met with responses like, "ah, but what if someone circumvents that?"... leaving the poor guy asking the questions feeling like there's some course he should pay for to learn this mysterious art.

 

And on the entire interwebs... nothing. And I simply can't belive that there's nothing to read anywhere because the FileMaker community is tight-lipped about discussing security.

 

I'm happy to be wrong but I'm done searching for something I might have missed, that's all I'm saying

[Steven H. Blackwell]

 

I'm saying that after 15 years of using FileMaker and never having seen anyone (expert or otherwise) actually indicate to any extent how a hacker might compromise a locked down FileMaker solution... It's quite safe to conclude that securing a soltuion is really, very simple.

 

 

The original poster, truelifeajf, has taken his position as stated in this thread.  In my view he confuses the Absence of Evidence about vulnerabilities with Evidence of Absence of those vulnerabilities.  This is very common, and it is understandable that he has done so.

 

I have never made a practice of describing in a detailed fashion what specific vulnerabilities are or how they work. My preference has been to find solutions to close those vulnerabilities and to mitigate the severity of the level of Impact a Threat Agent can cause if that agent triggers an attack using one of any number of potential vulnerabilities. I then distribute that information as widely as I can. I do not plan to alter that practice now.

 

All that said, here are a few specifics. All these presume that the file is opened with an Account that confers some level of Privileges as defined in the security schema.  Note:  the security schema, not the UI.

1. Any script that is either modifiable or executable to the Privilege Set may be able to be run from an external source outside the file in which it is defined. The script does not have to be visible in the Scripts menu.  There does not even have to be a Scripts Menu. This can be accomplished by external file references if they are available. It may also be accomplished by any of several external API’s.  This can include Apple Events, Active X Methods, XML CGI’s, and ExecuteSQL in some cases. Some of these openings can be closed completely; others can be closed partially.

    

2. Any script that is modifiable to the Privilege Set can be read in plain text absent blocking external file references and/or removal of Full Access Accounts with the Developer Tool.

    

3. Any field in any table to which the Privilege Set has read/write access can have its value changed from some of the external API’s. Any field that has read-only access can have its contents read in a similar fashion. The field does not have to be on the active layout; it does not have to be on any layout.

    

4. Any layout that is accessible to the Privilege Set can be viewed by use of an external API or, absent its blocking, by use of an external file reference. Again, the Layouts Menu is of no consequence or effect here.

    

5. If data are accessible to an External API, they may be exported or printed from that external source, irrespective of settings in the Privilege Set. As I noted in the earlier post, “…a number of privileges associated with a particular Privilege Set apply only to the file in which they are defined.”  

    

6. The External API’s, the external file references, and the Design Functions can all return a wealth of information about layout names, script names, field names, file names, field types, field comments, Layout object names, Relationship names and information, Value List names, Value List items content, etc. All this furnishes information about the nature and structure of the files that can aid the attacker.  That is why I noted that this information could be “…used for further intrusions into the files.” Some of this can be completely controlled; some of it can be partially controlled.

 

So when you think as the attacker thinks, basically you ask:

What is the controlling mechanism for the protection restrictions?

1. Can I break it?
2. Can I manipulate it?
3. Can I by-pass it?
4. Can I turn it off?

In my view and experience the UI is not a reliable vehicle for enforcing security restrictions.  Indeed, the UI can impart a false sense of security, causing the developer to ignore other vulnerabilities. What behavioral psychologists and security researchers refer to as “probability neglect” comes into play here.  Developers focus on what they think protects their file.  They ignore what the actual vulnerabilities are that an attacker might exploit; and, they ignore the relatively high probability that the attacker will actually ignore or bypass their focal points to attack the file.

 

I have said now about all I plan to say about this topic, at least for now. I may have more to say later in a different venue or perhaps here as well.

 

This has been an important thread, one of the most important ever to appear on FM Forums.  I encourage all to disseminate a link to this thread via various social media and/or private FileMaker lists.

 

Thanks for the opportunity to participate here.

 

Steven

[truelifeajf]

Hi Steven, and thanks for the extended reply.

 

I'm not sure if you deemed this thread to be one of the most important threads on FM Forums before your latest post or during it, but I'm not sure how anyone could consider this thread useful.

 

If I were to show someone this thread (eg, via various social media), I think they would see this:

 

1) OP asks if securing the "code" of a a STANDALONE FileMaker solution is more complex than he thinks it is

2) The replies speak generally about concepts and ask rhetorical questions but provide no answer to the OP's question

 

Result: no one has learned anything = pointless thread.

 

The general examples you have given were prefaced with, "All these presume that the file is opened with an Account that confers some level of Privileges as defined in the security schema."

 

So when you say, "Any script ... may be able to be run from an external source outside the file in which it is defined."... what you're saying is:

 

"If the account privileges allow the modifying of a particular script then that script is vulnerable." Of course, so you make sure all your scripts are not modifiable.

 

Or (and) perhaps you're saying:

 

"If the account privileges allow the execution of a particular script then that script is vulnerable if someone can set up an external file reference pointing to your file." Of course, so you make sure your file has enabled "require full access privileges to use references to this file".

 

To me it seems that each example you gave is a vulnerability when someone doesn't secure their file using the basic FileMaker security methods.

 

My point is, if ALL of the available FileMaker security options are turned off / locked down, I'd love to know exactly how (just one example would do) someone could circumvent that.

 

All other examples either relate to server / API security, or the protection of the actual data within a FileMaker file. My question is about protecting the "code".

 

You ask these questions:

 

Can I break it?

Can I manipulate it?

Can I by-pass it?

Can I turn it off?

 

And of course they're great questions. But you, nor anyone else has ever answered those questions. The result is multiple threads (including this one) go like this:

a) Hi, how can I secure my intelectual property?

Well, ask yourself... "can I break it?"

c) Um... I don't think so... that's why I asked

d) silence

 

I too have said all I plan to say about this topic and I may have more to say here, or at the breakfast table... but until we stop asking generic questions while not providing any kind of answers other than maybe via purchasing some product, or attenting some special conference, I'd feel that anyone reading this would ask, "perhaps there's nothing more to discuss beyond the basics already discussed?"

 

I'm certainly not of the position that the absence of evidence about vulnerabilities = evidence of absence of those vulnerabilities. I'm always open to the possibility that aliens exists, but currently no one is able to sit me down and say, "look... I'll show you."

[comment]

 

All other examples either relate to server / API security, or the protection of the actual data within a FileMaker file. My question is about protecting the "code".

 

Without entering the (most interesting!) discussion above, I'd like to point out that a "stand-alone file" is only stand-alone for as long as you don't put it on a server.

Note also that in his point #6 Steven specifically addresses "information about the nature and structure of the files" - i.e the schema of the solution, not necessarily the data contained by it.

On another note, Asimov once remarked that "no machine can be of secret design if the machine itself is available for sufficiently intense study." Someone knowledgeable enough to hack your solution is likely to be knowledgeable enough to rewrite it from ground up, using your file merely as a guide to the intended behavior - see:

http://en.wikipedia.org/wiki/Clean_room_design

[truelifeajf]

Hi comment,

 

I'm only talking about stand-alone... not on a server.

 

Point 6 is just waffle, like all the other points. To translate what he's said into something real world... I think he's trying to say, "If someone can access a database design report, or have an external file link to your file in some way then it can get information about the file structure which is not good."

 

The answer is simple... don't have any users who can access the database design report, and don't allow other files to reference your file without full access authorisation. And if it's not that simple... then we'll never know because he doesn't want to enlighten us.

 

He then says, "Some of this can be completely controlled; some of it can be partially controlled."

 

For example???

 

This thread is actually getting tiring as it's not offering anyone in this forum anything useful.

 

I asked the question whether my knowledge on securing a stand-alone solution was sufficient and currently no one has said, "it isn't and here's an example". Instead we're talking about "probability neglect" as if we're politicians trying to dodge a direct question.

 

I guess if makes people feel good, then go for it.

[comment]

I'm only talking about stand-alone... not on a server.

 

I am afraid you've missed my point: you may be talking about stand-alone, but a file is a file - once I have your file, I can put it on a server and expose it to APIs that are unavailable in the client.

As for the rest, I said I don't want to get into it. Let me suggest a theory, though:

There are potentially two kinds of vulnerability your file may have; one is due to your failure to do everything you can (and should) do to secure your file. The second kind is due to inherent issues in the file's structure over which you have no control; we could call them vulnerabilities due to FMI's failure to do everything they could to secure the file.

I am not privy to any confidential information coming from FMI, so I can talk freely about the second kind, if I so choose (that may not be true of other participants in this thread). There is one in particular that I don't mind mentioning, since FMI themselves let the cat out of the bag when they released version 11. In all previous versions you could create a reference to the attacked file in a file of your own and gain access to actions that were denied to you when you opened the file directly.

Now suppose this discussion were taking place when version 10 was the current version: would you expect me to talk about this openly?

[truelifeajf]

Well yes, and good point that a file can be put on a server... then my question would extend to "what specifically could someone do by putting it on a server"... It's still the specifics that are missing (even a basic example).

 

And your example of file references in earlier versions of FileMaker is a good one, but I am talking about FM12.

 

If we were talking about V10, I would absolutely expect there to be open discussion about the security issues. While I'm sure many might disagree, that's an irrelevant discussion (in this thread anyway)... my issue is that in every security / intellectual property thread on this forum, people have wanted to discuss ways to secure their file and I feel as though they (and I, in this thread) are shut down with obtuse, mysterious questions... "ah, but what if that can be circumvented?" as if they haven't thought hard enough but the issue and there's some obvious way someone could hack their file. Why can't the answer be this:

 

"You might want to consider implementing <xyz> which is covered in <this link / PDF>. Beyond that, there's not a lot more you can do in terms of FileMaker's security settings, so doing abc in your files will add another layer of protection. Also consider that a serious attacker could actually do <this GENERAL thing>, which I don't really want to discuss because my belief is we shouldn't be talking about this stuff openly, but let's just say that there are ways they can get access to those scripts quite easily, so here's my suggestion on how to minimise those inherent risks."

 

That would be an excellent discussion where we could all learn without "letting the cat out of the bag".

 

Although, I tend to believe any vulnerabilities are actually ones over which we have no, or very little control... and are probably vulnerabilities that are highly unlikely to be a risk anyway to little ol' me anyway. I'm guessing there's no case studies? statistics? Or are we not allowed to talk about that either?

 

Perhaps the ones being tight-lipped are the ones earning a profit from selling security seminars? No idea.

[LaRetta]

 

 

Perhaps the ones being tight-lipped are the ones earning a profit from selling security seminars? No idea.

 

Well, I'm all for a good discussion but you are attacking and in a backhanded (obviously biased) approach at that.  Please control your animosity.

[comment]

Well, that was my 2 cents. One of the reasons I don't want to go deeper into this is that while I sympathize with some of the points you have made (I could even say, share your frustration over them), I cannot say the same regarding the attitude you have taken. In fact, I think you may have crossed the line of personally attacking your fellow forum members - and I don't want to take any part in that.

 

 

---

EDIT:

LaRetta posted just as I was about to post this - so now you have two people telling you ....

[truelifeajf]

My comments about "those selling seminars" are not directed at anyone in particular as I don't know anyone in that specific industry who sells security information. But if anyone is in that industry and felt it was directed at them then I apologise.

 

I still think it's a fair conclusion though. It's like the "life extension" industry... everywhere you look there are a bunch of products but no one can really give any data / examples on how their product is making people live longer. It's an industry largely based on distributing fear.

 

As I grapple with wanting to know more about security of my solutions, I tend to think the FileMaker security industry possibly suffers from the same issue.... a lot of scary questions but the answers aren't anything special.

[Fitch]

There are probably only a handful of developers who know any more than you do about how to bypass a file's security (I'm not one of them). Other than that recent post that went slightly over the line, I have to say I agree with your statements and I appreciate your pursuit of this issue. I also appreciate Steven's POV that it can be a delicate subject when operating as we do in a closed-source platform that relies somewhat on security through obscurity. Your best bet is probably to invite him or others to give you an example back-channel, or if your IP is worth significant $$, hire him for an hour -- or hire a hacker to try to break in.

[Rich S]

(Just to throw this into the mix for someone to comment on)

 

Runtimes in particular--compared to standalone FMP files--are (supposedly) harder to hack.

[Steven H. Blackwell]

There is no difference between a data file opened by the runtime engine than there is in the same file's being opened by FIleMaker Pro itself.  it is a FIleMaker Pro file in either instance.

 

The difference lies, not in the data file, but in the executable that opens them. The runtime engine has a number of design features found in the regular versions that have been disabled or removed.  But the files themselves can be opened with FIleMaker Pro and are subject then to the permission restrictions set for those files before the runtime engine was created.

 

I hope this clarifies this matter.

 

Steven

[carlosnorvik]

Read the following link about keyless BMW being stolen, even security developed by a high tech company can be cracked by determined hackers.

 

http://www.networkworld.com/community/blog/high-tech-car-theft-3-minutes-steal-keyless-bmws

 

The analogy applies to FM and to  everything which tries to be secured, even to a primitive door lock.

 

There are some that are extremely easy, for example a file made in a famous word processor, secured by a pw against modification (read only w/o the pw) is easily modified in an open source word processor, I found that out many years ago and I just tried while writting this, surpisingly, it can still be done.

[TKnTexas]

I had some runtimes that I created to use at my job, to make my work easier.  I forgot the passwords.  Using PASSWARE on my Win7 partition, I was able to strip out the passwords for all users defined in the runtimes.  Also worked on the *.fp7 files I had.  I had not removed anything prior to creating the runtime.  They were for my use only.  

Sidenote: my boss liked two of them and added Filemaker Pro 11 to the software tools used in our department so I could really develop the tools.

[Steven H. Blackwell]

 

I have said now about all I plan to say about this topic, at least for now. I may have more to say later in a different venue or perhaps here as well.

 

 

Here is some additional information:

 

http://fmforums.com/forum/blog/13/entry-777-protect-your-filemaker-server-and-files-from-a-vulnerability/