RATING: Intermediate
PLATFORM: Macintosh/Windows
VERSION: FileMaker 5
TECHNIQUE FILES: Defaults.fp5, LoginMagic.fp5, Personnel.fp5
Author's Note: This brief article will not attempt to discuss all the issues associated with FileMaker's built-in access privileges or standard script security issues. Those subjects have already been explored extensively in other articles and books. Instead, we will look at how to build on those basic levels of access security. We can create a customizable login procedure that is much more flexible and gives us added levels of security by using four excellent FileMaker plug-ins: DialogMagic, SecureFM, the Troi Coding plug-in, and Crypto Toolbox.
Plug-In: DialogMagic
Version: 5.5.4
Company: New Millennium Communications, Inc.
Web: < http://www.newmillennium.com/plugins.htm >
Plug-In: SecureFM
Version: 5.5.4
Company: New Millennium Communications, Inc.
Web: < http://www.newmillennium.com/plugins.htm >
Plug-In: Troi Coding
Version: 1.5.2 or later
Company:Troi Automatisering
Web: < http://www.troi.com >
Plug-In: Encryption Toolbox
Version: 1.0v1 or later
Company: David McKee
Web: < http://www.geocities.com/SiliconValley/Network/9327/plPLUGs.html >
To show you their capabilities, I'll follow the techniques used by New Millennium's free LoginMagic tool as an example file.
Product: LoginMagic
Company: New Millennium Communications, Inc.
Web: < http://www.newmillennium.com >
LoginMagic Overview
The LoginMagic techniques, using these four plug-ins, allow you to create a highly customized login procedure that adds new layers of security to FileMaker Pro's built-in access privileges.
The LoginMagic file can be thought of as an 'opener' file, the file initially opened by the user for your solution. Once it is opened and the login process is successfully completed, it automatically launches all other files in your solution.
The other files in your solution should be set up with a FileMaker password or passwords with basic access privileges defined - but the FileMaker passwords should not be given to the users. They will be entered into a field in the LoginMagic file and encrypted.
In our LoginMagic example, we include two additional files: Defaults.FP5 and Personnel.FP5. These are essentially placeholders for files you are already likely to have in your solution.
The Defaults file should be a well-secured file using FileMaker's access privileges. This is a file containing essential data that the average user does not have access to, such as a central administration file.
The Personnel file is the file in your solution that stores basic user information.
The essential elements of LoginMagic's approach are as follows:
? User Login: Users immediately encounter a login layout requiring a valid user name and password.
? Encrypt Login Data: All sensitive user ID and password information is encrypted using the Troi Coding plug-in.
? Validate the Login: The encrypted user ID and password is compared to the stored encrypted ID and password.
? Protect the Login Session: Using Crypto Toolbox, LoginMagic prevents a login session from being co-opted by another user on another machine in the network.
? Set Custom User Name: DialogMagic is used to set FileMaker's Custom User Name, ensuring that when a user logs in, the correct name will be used in all of your solution's Status(CurrentUserName) calculations, no matter which workstation is used.
? Control FileMaker Menus and Functions: SecureFM then controls access to FileMaker's menu items, toolbars and keyboard commands based on the user's privileges.
? Open Solution Files: Once the login data has been verified and the FileMaker environment made secure, LoginMagic then opens the remaining files in your solution, using DialogMagic to open them with the appropriate FileMaker Pro passwords.
? Change FileMaker Passwords: FileMaker passwords can be changed in all files in the system with one button using DialogMagic.
To understand LoginMagic's use of the four plug-ins, let's go through the core scripts that manage the file's startup and login.
In order to see the normal login process, launch the LoginMagic file normally. You will be presented with a login layout. Enter the following information:
User ID: Demo
Password: 12345
The User ID and Password are case sensitive.
When you are ready to look at LoginMagic with master access, exit the files and relaunch them. Hold down the Option key on Mac or Shift key on Windows while the LoginMagic file is starting up.
- Enter "master" into the FileMaker password dialog.
- Use the normal User ID and Password again.
- Click the LoginMagic button at the bottom of the Personnel layout.
- Select the third script ("Halt and Open Status Area") from the Scripts menu.
Now, let's look around…
User Login
This process begins with the "On Startup" script and quickly shifts to the "Login Main" script. If the user name and password are recognized, the "Login Successful" script manages the rest of the login subscripts; otherwise, the login procedure is begun again or the script quits FileMaker Pro.
The "On Startup" script is, of course, set to be run when the file is launched in the Document Preferences. The script initially performs a couple standard security steps - Allow User Abort [Off] and Set Status Area [hide, lock] - in order to prevent users from halting the login scripts or bypassing required layouts.
If Status(CurrentUserCount) = 1, flag fields are set to temporarily prevent other users from logging in or opening other files in the solution. This is a precaution to avoid login conflicts that might occur on a networked solution.
The four plug-ins should then be registered. (The documentation available from their web sites should clearly explain how to do this.)
Finally, the "On Startup" script calls the primary script "Login Main."
One of the first things that the "Login Main" script does is to call the "Set Password Key" sub-script. The sub-script uses the Troi Coding plug-in's Set Crypt Key command:
Set Field [Result, External("Troi-Set Crypt Key", "qwerty")]
The letter combination "qwerty" is being used as an encryption key. This encryption key must be used every time the login data is encrypted or decrypted. You should, of course, use a different encryption key for your own files.
The "Login Main" script next goes to the Login layout. This is a simple layout with two fields with the labels User ID and Password. The text color of the password field is set to be the same color as the field's background to prevent viewing of the password as it is being typed. Once the Enter key or button is hit, both fields will be encrypted, further protecting them.
Next, we have the "Login Main" script enter a loop with a Pause/Resume Script step at its heart. Combined with the Allow User Abort [Off] step at the script's beginning, this sets it up so the only way the user can exit the script is by clicking one of the buttons on the layout or by hitting the Enter key. Even when it appears to the user that nothing is happening and the file is simply waiting for a User ID and Password to be entered, the file is still running a script that the user cannot bypass. This loop/pause technique is useful when the user must enter data but, for security reasons, you want to lock the user into a controlled process.
All of the buttons on the Login layout are set to resume the paused "Login Main" script (see the Specify Button dialog for each button), as well as call a script that marks a field indicating which button has been clicked. Hitting the Enter key will also resume the paused script.
Encrypt Login Data
Still within the "Login Main" script's loop, but now past the Pause/Resume Script step (since the user has either clicked one of the buttons or hit the Enter key), the "Encrypt Login" sub-script is called. This script once again calls the sub-script to set the password key (see above), and then uses the Troi Coding plug-in to immediately encrypt the global fields being used as the User ID and Password fields, respectively:
Set Field [Global Login User ID, External("Troi-Encrypt", Global Login User ID)]
Set Field [Global Password, External("Troi-Encrypt", Global Password)]
It is only at this point that the "Login Main" script checks to see if the Loop should be exited. The loop/pause is only exited if-
- A valid password has been entered, or
- The Cancel button has been clicked, or
- Too many login attempts have been made.
In the last two cases, the script quits FileMaker Pro, preventing access to any of the files.
If none of those cases is met, the global fields are decrypted (using the "Decrypt Login" sub-script), the login counter is increased by one, and the loop/pause starts over again.
Validate the Login
LoginMagic knows that a valid login User ID and Password has been entered through the use of a field calculation that is dependent on a dynamically set relationship. In the LoginMagic file, we use a field named Login Is Valid with the calculation:
IsValid(Login::User Login Key)
The Login Is Valid calculation equals "1" when the Login relationship finds a match. This requires a little explanation.
The Login relationship is a self-relationship within the LoginMagic.FP5 file. A match only occurs when the Global Login Key Calculated field matches the calculated User Login Key field.
The Global Login Key Calculated field is simply a concatenation of the User ID and Password fields on the Login layout, divided by a pipe character:
Global Login User ID & "|" & Global Password
The User Login Key field is the concatenation of the equivalent fields set up by the administrator in LoginMagic's Users table:
User ID & "|" & User Password
When the two calculated keys match, a valid self-relationship occurs within the LoginMagic.FP5 file, and the Login Is Valid field calculates as "1" - the login is valid.
When the login is valid, the 'Login Successful' script is called.
Protect the Login Session
The first couple of steps in the "Login Successful" script use the Crypto Toolbox plug-in to protect the login session so it can't be co-opted or spoofed.
The issue, briefly, is this:
A common technique used in login systems is to store the logged in User ID in a global field. But suppose a user logs in legitimately as himself, and then he manages to put that User ID field on a layout. Once that is done, the user can manually type in any other User ID or Set Field via a relationship, convincing the system that he is another user. This is sometimes referred to as stealing the login session.
To avoid that, LoginMagic does not store a User ID anywhere in a global field. The only thing it does store is a random number. That random number is combined with a unique machine ID, linking that specific login session to that specific workstation.
The unique machine ID is a value returned by the Crypto Toolbox plug-in's crypt-VSN command. On Windows, the value used is the serial number of the C drive. Every Windows machine has its own C drive with a unique serial number. On the Mac there is no C drive, so, instead, the plug-in returns the address of the Ethernet card. This is also a unique number. If there is no Ethernet card, the Crypto Toolbox returns a time/date stamp.
The basic calculation used concatenates the unique machine ID, a single space, and a random number:
External("crypt-VSN", "") & " " & NumToText(Round((Random* 100000),0))
This value is calculated and set into the User Ob Key field (User Obfuscation Key) within the LoginMagic file and, later, in the Personnel file. In addition, the random number is stored in the central (Defaults) file, allowing the file to hardcode the User Ob Key as a calculated field within that file as well. Even if a knowledgeable user managed to change the User Ob Key in the Personnel file, the calculation field in the Defaults file can neither be modified manually nor by any other method, such as a Set Field script step.
Using these two key fields, we now have a relationship from the Defaults file to the current logged in user in the Personnel file.
Any attempt to modify either the random number in Defaults or the User Ob Key in Personnel breaks the login session's validation. This can be checked at any time by running the simple "Check Valid User" script in the Defaults file. To make sure the script is run regularly, you can include it as a sub-script for every other script called by a button, for example. Another option is to run it at regular intervals with a plug-in such as oAzium Events. If the "Check Valid User" script fails, it immediately quits FileMaker, booting the false user out of the system. The login data is again encrypted with the "Encrypt Login" sub-script described above.
Set Custom User Name
The "Set Custom User Name" sub-script uses DialogMagic's DM-AppPrefs function to automatically set the logged in user name into FileMaker's Application Preferences user name field:
Set Field [Result, External("DM-AppPrefs", "0|0|0|"&Current Logged In User::User Name)]
Open Application Preferences
This makes sure that when a user logs in, the correct name will be used in all of your solution's Status (CurrentUserName) calculations - even if the user is logged in to a workstation other than their own.
To further prevent the user from manually changing the FileMaker user name, SecureFM will disable access to all FileMaker Preferences in the next step.
Control FileMaker Menus and Functions with SecureFM
The "Set User SecureFM from Login" sub-script gets most of its work done in the "Current Logged in User SecureFM" script. This script uses SecureFM's powerful Menu-Disable and Menu-Toolbar functions to precisely control which FileMaker functions are available to the user.
Set Field [SecureFM Response,
External("Menu-Disable", If(Status(CurrentPlatform) = 1,
SecureFM Mac String & "|" & LoginMagic Defaults::SecureFM Password,
SecureFM PC String & "|" & LoginMagic Defaults::SecureFM Password))
The SecureFM Mac String and SecureFM PC String fields contain the menu configuration strings used by SecureFM to determine which FileMaker menu items to disable or remove. The contents of these configuration string fields can be modified in the Users - SecureFM layout, which is accessible only to someone with an administration-level password. Also, the SecureFM configuration strings are set up in the LoginMagic file to be user-specific, meaning the system administrator can give each user his or her own unique FileMaker menu configurations!
It is important to point out that, at a minimum, FileMaker's Preferences command should be disabled for all users in order to prevent them from manually disabling these plug-ins by simply unchecking them in Application Preferences. Disabling Preferences also prevents users from changing their user name.
The SecureFM Password field used in the script above contains an optional password that prevents even knowledgeable FileMaker users from changing the SecureFM menu configuration. If a password is used, the only way to then modify the SecureFM menu configuration is to again use the same password.
This script also allows you to remove FileMaker's toolbars which, otherwise, give users access to such powerful commands as Delete Record, Create New Record, etc.
Set Field [SecureFM Response, External("Menu-Toolbar", User SecureFM Toolbar String & "|" & LoginMagic Defaults::SecureFM Password)]
(For more information on SecureFM and how to generate different configuration strings, see the SecureFM Editor file and User Guide included with the free SecureFM demo download available at the New Millennium web site.)
Open Solution Files
Once the login data has been verified and the FileMaker environment made secure, LoginMagic then opens the remaining files in your solution, using DialogMagic to open them with the appropriate FileMaker Pro passwords. This is managed by the "Open Files Main" script.
The FileMaker password necessary to open the rest of the solution's files - not to be confused with the individual users' passwords - must first be decrypted. Again, we use the Troi Coding plug-in to do this:
Set Field [Global Password for Opening File, External("Troi-Decrypt", File To be Opened Password #Record #::Password)]
The actual files to be opened are controlled by the "Open Files Conditional" script.
In the "Before File is Opened" sub-script, if the file about to be opened is already open for some reason, it is immediately closed to make sure it is subsequently opened with the correct FileMaker access privileges. DialogMagic's DM-OpenPassword command is then called along with the now decrypted FileMaker password:
SetField [DM Response, External("DM-OpenPassword", Global Password for Opening File)]
When the file is then opened back in the "Open Files Conditional" script, DialogMagic will automatically enter the password into FileMaker's Open Password dialog. The user is never required to enter a password other than during their initial login procedure. In fact, with this DialogMagic technique, the user does not even need to know the file password necessary to open the actual FileMaker files. Doing this, we have, in effect, created a login shell.
Once all files have been opened, the "Open Files Main" script then clears the Global Password for Opening File field, preventing the possibility of a user viewing the unencrypted FileMaker password.
That is all you need for a complete and secure login procedure using the DialogMagic, SecureFM, Troi Coding, and Crypto Toolbox plug-ins.
Change FileMaker Passwords
To give you a further example of the possibilities of these plug-ins in a login system, let's look at how LoginMagic uses DialogMagic to give administrators the ability to change the FileMaker passwords for all files in the solution with the single click of a button.
This process is initiated by clicking the Change Password button in the administrator's Passwords layout. The administrator is asked to enter a new password and DialogMagic does the rest!
The "Change Password Main" script begins the process.
First, the list of FileMaker passwords necessary to open each file are decrypted using the Troi Coding plug-in:
Set Field [Global Password for Opening File, External("Troi-Decrypt", Current Password::Password)]
Next, all of the files to be changed are opened.
Now within the "Change Password Conditional" script, we use DialogMagic's DM-Password command to specify the old and new FileMaker passwords:
Set Field [DM Response, External("DM-Password", Global Password for Opening File & "|" & Global New Password)]
A "Change Password" external sub-script is called for each file. The external scripts each contain a single script step: Change Password. DialogMagic automatically fills in the old and new password data in the resulting change password dialog.
This simple process is repeated for each file, quickly changing the FileMaker passwords for the entire solution!
The process of changing a password for all files in a solution is explained in greater detail in the DialogMagic demo files available for free from New Millennium Communications.
***
With just a few techniques and the DialogMagic, SecureFM, Troi Coding, and Crypto Toolbox plug-ins you can build a robust login process into your existing FileMaker solutions, adding layers of greater security and interface customization.
I encourage you to explore the LoginMagic scripts further as well as the documentation available for each plug-in to discover additional possibilities for your solutions.
Happy FileMaking!
Ivan Granger and Todd Geist are lead software developers at New
Millennium Communications. Todd is the designer of LoginMagic. Ivan
is the primary author of this article and is the designer of the
demonstration files for all of New Millennium's plug-ins.
Email New Millenium Communications, Inc. for any information regarding their excellent plug-ins: <info@nmci.com>