Recommendation on secure password for FMP files

[Johds]

Gents,

While developing a solution, one of my betatesters informed me that he had been able to get the masterpassword by using one of the FMP password cracker programs.

I have then checked that program out, and true enough, it can get the password both from a standard FP5 file as well as from a Runtime file where everything has been used to protect the file.

Does anybody have an idea to how one can avoid this problem ? Using special chars or such ?

Any recommendation would be appreciated.

Just my 0.02

[CobaltSky]

Hi Johds,

Your beta tester has certainly done you a favour by alerting you to a problem. However there is another problem that you might also like to consider.

Yes, there are a number of methods of fooling password crackers *but* in the past, when developers have published such on public lists such as this one (and even on some of the highly restricted lists), updates to the cracking utilities which defeated the work around have appeared promptly - sometimes in less than 48hrs from the time of the post. The hackers and hack-tool publishers keep a keen eye on forum threads such as this one.

What that means is that you would be unwise to use any suggestion (on a topic of this kind) that you find on a forum. Even if the hacking tools are fooled now, you can count on it, by the time your solution reaches the end users there will be a current version of one or more hacker tools that nullifies your efforts.

The same is true to a lesser extent, of any technique that any other developer is prepared to share with you - publicly or privately. That is because if it is being shared, you can rest assured it will reach the ears of the hackers sooner or later - probably sooner. The most secure methods are those that are devised and tested by individual developers or teams and then divulged to no-one - and even those provide no absolute surety.

My advice is to experiment until you come up with a few options of your own that work, and then tell them to nobody. The more obscure and the less well known the techniques you use are, the more secure they will be.

That said, things are not quite as bad as you seem to suppose, because even though hacker tools may reveal a master password of a file that has been secured with the Developer Tool (FMD), that password will nevertheless provide only limited access. Field definitions, layouts, scripts and relationships will all remain locked. A master password obtained in this way may assist a hacker to get at the data in your files but is not so much use when it comes to accessing the code.

If you want to go further, you might find it useful to look at the NMCI Password Administrator software, which provides some additional options and safeguards (as well as some time saving developer features).

None of the above techniques will give you complete peace of mind. But what they *will* do is reduce the proportion of the population who can get past your defences to a fraction of what it might otherwise be.

[Johds]

Ray,

Thanks for a good and usefull answer.. Appreciated. The NMI software you mentioned, I can't seem to find any references to. Have tried to google, but alas, no usefull links. Could you please provide a siteadress ?

I will try to find some possibility to defeat at least the cracker program which my betatester sent me, and otherwise the fact that the developer security options at least only give them access to the data, is a better than nothing solution, which I can live with, in the same manner as having to pay tax

Thanks again for your time, it's appreciated.

Just my 0.02

[CobaltSky]

Hi johds,

The link you were looking for is:

http://www.nmci.com/Product_Overview.htm?pid=P703XLMOYQF6ISLDU2DJ&-session=dwc:93F333609E30F613DE2C2DA113A8ABD4

FWIW, you will find that a useful way to locate FMP plug-ins is via the listings on the FMI site under developer tools. For instance, Password Administrator is listed in the FMI directory at:

http://www.filemaker.com/plugins/Dialog.html

However in this case, just try the above link and it will take you direct to the product overview page for the Password Administrator pi.

[BobWeaver]

In my opinion, there is no significant password security for Filemaker files. I have yet to find a method that can't be defeated in a couple of minutes.

So, if you distribute your solutions, you must assume that someone will be able to get into them no matter what you do. For that reason I recommend that you don't distribute free demo versions of your solutions that can be turned into fully functional versions by means of a password.

[djgogi]

Ray, I don't want to start over this discussion, but you should really not rely on Developer's master password "fix".

It will remove only the "human readable" part in field definition (the calculation formula only), everything else including scripts, layouts etc. is access-able.

As regarding other resources you've mentioned, they suffer the same problem.

I'm agree with Bob:

Until frameworked version of FM I'll suggest to not deliver workable demos.

Dj

[CobaltSky]

Hi Bob, Hi Dj,

I assure you, I don't rely solely on the 'fix' as you call it. And in essentials I don't believe we are in disagreement.

What Bob says about a couple of minutes is true as far as it goes, but it omits to mention that the individuals who have the skills required to perform the said operation within two minutes are by no means a majority of users, nor even of professional developers.

Of those who do have the skills, a still smaller proportion have the inclination to use them to steal from others.

By and large, the individuals we are talking about also have the ability to build their own version of whatever it is that they are hacking into - so there is little intellectual property value for them and they are scarcely part of the end-user market for most solutions.

I've never suggested that there is any surety or total security. But I stand by my assertion that there are available techniques which suffice for the majority (ie they increase the level of difficulty for the would-be hacker and thereby reduce the risks to acceptable levels for most purposes).

[djgogi]

Hi Ray,

generally speaking, I'm agree with you, but if we continue to retain that FM is secure and that the risk of being hacked could be decreased by implementing some homemade security procedures is fooling ourselves.

Instead, it should be FM responsibility to provide "secure" framework for both user's data and developer's code.

Actually FM is lacking both.

Since I'm in house developer, most of time I don't need to worry about if my intellectual work could(will) be hacked (it's widely open source code and I'm willing to share it with others in our company)

On the second hand I do crete "external" solutions which I would prefer being "black boxes" from user's point of view.

They (users) should see only what I've declared public, for ex:

Subset of scripts (and only names of those) accessible thru Scripts menu

Only fields declared as public (or user) should be enabled for manual input etc.

Now, it is true that most of times the basic protection scheme would suffice to prevent solution being hacked, but the problem is that by increasing the complexity of protection scheme (and hence augmenting the time/cost parameters of the product) will not increase the overall security of our solution due to the lack of inner mechanism (that should be provided by FM) on which this procedure(s) should be based on.

Finally, I think that you are overestimating the level of knowledge needed to bypass FM protection scheme (at least as it is implemented now)

To resume, until the arrive of database framework, with separated data and functionality layers I will not create full functional demos and I'll continue to work on only user commissioned solutions.

My hope is that by insisting with requests for more native security (and hence finger-pointing the lacks in the actual security schemes) will finally result in better and more secure app provided by FM Inc.

Dj

[BobWeaver]

the individuals who have the skills required to perform the said operation within two minutes are by no means a majority of users,

True enough, as long as cracker programs aren't freely available for download off the internet. Fortunately, I don't know of any free ones that will work with current versions of Filemaker files.

To break into a protected Filemaker database with the intention of profiting from the result, requires one to be both dishonest, and slightly ambitious. These characteristics (in my opinion) usually tend to be mutually exclusive. But you have to judge each situation on its own merits.

If you are selling to corporate customers, then you likely don't need to worry too much about getting ripped off.

On the other hand, if you are distributing your solution to the general public over the internet, you will have to assume that a lot of people will be able to unlock it and use it for free. So, you have to set your selling price low enough to maximize the number of paying customers, but high enough that you are making a profit.

Since you likely aren't going to decide not to sell your product just because you can't make it perfectly secure, you simply have to make it as secure as you can. In that case, I think the best bet is to use the developer tool to strip the design info, and the NMI software to protect the passwords. The former will protect them from anyone except Dj (unless he decides to distribute his database recovery software ), and the latter will protect them from most cracker programs, unless there are some fancier ones available now that I haven't seen (and there most likely are).