by Paul Evad, <paul@kudosnet.com>
Put a Padlock on Your Solutions
An overview of probably the only way to ensure your files don't get hacked...
BONUS: padlock.fp3
PLATFORM: Mac/Win
We all deal with the issue of security at some point in time, whether we are working in a corporate environment, jumping into the shareware market, passing demos on to clients, or writing full blown commercial solutions.
Most of us have been aware for quite some time that FileMaker password protection falls short of locking hackers out of databases. The reality is, if someone really wanted to break into your password protected database... they could (at least those who know how, or are persistent enough to find out - don't bother asking me I'm not about to promote hacking in the FileMaker community).
The technique outlined in this article is one of the better methods of securing your database from hackers. However, it's not the only one. To be truly effective you need a combination of tricks.
This Technique takes advantage of a quark in FileMaker Pro 3.x where you can have two or more password identical. Once the file is locked up in 3.x, it can be successfully unlocked in either version 3 or 4.
A Word of Caution
Before you go off and implement this locking method into all of your databases, I would caution you that if your not careful... you'll lock yourself out, too. Always make sure you have an unlocked backup before proceeding.
I first learned of this technique at the Claris Solutions Conference held earlier this year. [Thanks to Steve Wilmes and Geoff Ryle for a great presentation, and check out http://www.swconsulting.com/ for some demo files on security.]
The Basic Principal
We are going to take advantage of a little quirk that FileMaker has that allows us to have two passwords that are identical. Yes, that's right, two passwords that are the same. FileMaker matches the incoming password from the user to the first password in the file that matches, ignoring the rest.
Starting with a file with NO passwords, create the "locked" or "limited" password first. For our example, we'll use "MyPass" (don't type the quotes of course) and turn off most functions (see screen shots in the bonus file). Next, we create the "master" password to access the entire file. For now, let's call it "Master"; we're not going to lock ourselves out just yet.
Under Document Preferences, set the default password to "MyPass".
For our example, we will be requiring the user to enter a "secret code" into a global field and invoking a script to "unlock" the solution. So, with a global field called secret code, we use a script called "do register": (comments are preceded with #).
Script Step/Options Script Parameters
Allow User Abort Off
# first make sure that we have a record, or globals won't work properly
Find All
If Calculation
Status(CurrentRecordCount) = 0
New Record/Request
End If
# let's not allow endless tries at this... could they guess the
# secret code?
If Calculation
reg_attempts > 20
Show Message Buttons:
"OK","",""
Data:
You've attempted this more than 20 times...
contact you@yourdomain.com for assistance.
Thank you for supporting shareware.
Halt Script
End If
# keeping track of attempts...
Set Field reg_attempts
Calculation
reg_attempts + 1
If Calculation
secret code = "yoursecretcode"
Show Message Buttons:
"OK","",""
Data:
Now you need to change the default
password. The old password is
'MyPass' enter cool as the new password
Change Password
Show Message Buttons:
"Cool","",""
Data:
Next time you open the database you
should have full access to layouts,
scripts and field definitions.
# I prefer to use a closing script to ensure we don't loose globals
Perform Script close
Else
Show Message Buttons:
"Bummer","",""
Data:
I'm sorry, that passcode is incorrect
End If
Of course, depending on the complexity of your solution, you may want to add more twists to this registration script. You can do things like hide the location of the button that activates the script so that the user relies on you to tell them how to find the right spot.
There is one caveat that you probably already see in this example -- anyone who knows your "secret code" can pass it on to others. You can lock down your solution even further by making your secret code based on some sort of calculation field [issue 22, section 6 by John Mark Osborne outlines an excellent method].
We're not quite done with this yet. In order to lock down your solution prior to distribution, you will need to change the master password. Create another script, hidden from the script menu, that simply calls the Change Password script step. Since it is hidden from the script menu, the only person who has access to it would be one who already has access to altering scripts.
Now for the magic... make a backup of your file (I can't stress this enough). Locate the change password script in the script editor and click perform. The old password in our example is "Master". Then, in the new password field, enter "MyPass", and again for confirmation.
Close the database. Now the two passwords are the same.
Now open it again. You will be effectively locked out from doing anything (other than what you gave permissions for).
When the user enter's the correct code in the global field and invokes the registration script, the 1st password in the database, with the limited permissions, will be changed to something other than what is in the "default password" setting. This, effectively, unlocks the database for use.
Try it with the bonus file: padlock.fp3 found in this issue. The secret code for the bonus file is "JumpinJiminy".
Closing thoughts
Before you madly go locking down all of your solutions, you might want to consider the pros and cons for yourself and your users. This technique does add a fair amount of complexity to your solution, and I wouldn't recommend it for solutions with a multitude of files. (though you could lock down one file, and base your protection around that). It's a good thing to weight the benefits of locking your files against the amount of time it will take you to do it, the increase in technical support it may generate, and the hassle it will cause your users.
There are a number of articles on the Web about this topic. Here are two that I've read recently and found to be very enlightening:
http://www2.semicolon.com/Rick/ShareSuccess/Hookware.html
http://www.shareware.org/gazer7/why.htm
And the final word... no one solution alone, that I know of, will stop all hackers. In my opinion, the time spent trying to foil those persistent few is not worth the effort in most cases.
## END ##
Paul Evád is the proprietor of a Kudosnet Communications Services, Webmaster of ISO Productions and other things too numerous to mention. <pevad@kudosnet.com>