Can you set a FM file license key that expires every year

[Johannvdg]

Hi All,

Can anybody tell me if it possible to add a fm security feature that allows you to set a license key on the file that has to be renewed each year?

We are in the process of giving a sister NPO a modified copy of our db, and would like to have some control over the use and distribution of said file.

Thanks

Johann

[jamesducker]

It can be done with some careful scripting. In its very simplest form:

if get(currentdate) > date (12,31,2009)

display dialog "Your licence has expired."

exit application

end if

You'd want to make that script run on launch (defined in the File Options).

In practice you would want to make it a bit more foolproof than that, to avoid people changing their machine's clock etc etc.

Hope that helps.

James

[Steven H. Blackwell]

You'd want to make that script run on launch (defined in the File Options).

In practice you would want to make it a bit more foolproof than that, to avoid people changing their machine's clock etc etc.

Why bother changing the clock when you can just bypass the script itself?

Steven

[Zcast]

wouldn't that have to be hard-coded into the solution every year then? And if your client wants to renew their solution, how would you go about "unlocking" it to allow them to continue to use it after they renew?

Edited September 22, 2009 by Guest

[Johannvdg]

So by the replies I assume it is not really possible at all?

[Vaughan]

Apple and Microsoft, with their near-inifinite talent and resources, cannot create license key systems that are 100% unbreakable.

Yes, it's possible to come up with something, but in general it will be easy to break or work-around.

Are you also prepared to provide support for the system?

[comment]

Apple and Microsoft, with their near-inifinite talent and resources, cannot create license key systems that are 100% unbreakable.

You are assuming they WANT to create unbreakable systems.

I don't think it's impossible to come up with something that wouldn't be "easy to break or work-around" - at least not (much) easier to break than Filemaker's own accounts & privileges system. For example, you could give the user an expiration date and a hash of said date. Then allow record access only when the computed hash of expiration date matches the entered hash AND current date is before expiration date.

Of course, it could be significantly more secure if Filemaker had some basic cryptographic functions. As it is, the challenge is to come up with a hash function that isn't too simple for a hacker to figure out, and OTOH isn't too heavy for Filemaker's calculation engine.

[Johannvdg]

Yes, it's possible to come up with something, but in general it will be easy to break or work-around.

Are you also prepared to provide support for the system?

Yes I will provide support, below is what I have come up with in the interm.

"

Set Error Capture [ On ]

Set Field [ temp1_global; Get ( AccountName ) ]

Set Field [ temp2_global_date; "2010/10/31" ]

If [ temp1_global = "Johann" ]

Show Custom Dialog [ Title: "Admin on board"; Message: "Hi Johann"; Buttons: “OK”]

Else

If [ Get ( CurrentDate ) > temp2_global_date ]

Show Custom Dialog [ Title: "User License Has Expired"; Message: "Your user license has expired, please contact

Johann for a renewal"; Buttons: “OK” ]

Pause/Resume Script [ Indefinitely ]

Exit Application

Else If [ Get ( CurrentDate ) ≥ temp2_global_date - 10 or Get ( CurrentDate ) = temp2_global_date ]

Show Custom Dialog [ Title: "User License Expires"; Message: "Your user license expires in " & temp2_global_date - Get ( CurrentDate ) &" days, please contact Johann for a renewal"; Buttons: “OK” ]

End If

End If

Set Field [ temp1_global; "" ]

Set Field [ temp2_global_date; "" ]

"

[Steven H. Blackwell]

This is run where, at the startup?

Steven

[Johannvdg]

This is run where, at the startup?

Steven

Yes at startup

[Steven H. Blackwell]

OK, since it is a trivial matter to bypass a startup script, how are you going to enforce this process?

Steven

[Johannvdg]

I am looking for a solution to that problem, any leads will be appreciated.

[Steven H. Blackwell]

Well first establish all the tests and processes in a single script if at all possible. Protect all the fields where the values might be held.

Then call that script as a subscript in many places.

This isn't perfect, but it's a lot better than relying on a startup script.

Steven

[Johannvdg]

Thank you for the suggestion, I will go ahead and do it.

[TheTominator]

Another option to enforce the startup script to be executed is to use two levels of user accounts. The default account has very limited access but can run the startup script.

The startup script logs into the second user account with normal access. The second account's password is known only to the startup script. Then the startup script proceeds to carry out all of the housekeeping tasks you require for normal user.

To avoid trouble with users trying to brute force their way in, I would disable the second user account and only enable it just before logging into it using the startup script. You would need to add the disable account action into the script run on closing the file.

If you are paranoid about such things you can try to avoid trouble with users trying to scan the FileMaker binary to learn the password to the second account. Assign a new randomly chosen password just prior to logging into the second account. The account password would not be hard coded and potentially discoverable in the binary.

Edited October 13, 2009 by Guest

[Steven H. Blackwell]

FileMaker Pro passwords are not stored in the files.

Steven

[TheTominator]

FileMaker Pro passwords are not stored in the files.

Normally no. I presume only a one-way hash of a password is stored by FileMaker as part of the built-in user account information.

But if you are using a script to automatically log into an account and the script is storing the password hard coded into a string then there could be the possibility that the string appears as cleartext in the FileMaker binary.

[Steven H. Blackwell]

But if you are using a script to automatically log into an account and the script is storing the password hard coded into a string then there could be the possibility that the string appears as cleartext in the FileMaker binary.

Maybe conduct a test to see whether this happens? Also, is there any possibility that the relog script could be manipulated?

Steven

[TheTominator]

Maybe conduct a test to see whether this happens?

I tried a quick test with a binary editor to find known string hard-coded into the password parameter of a Re-Login script step. I was unable to find the string as typed. This suggests to me that FileMaker obfuscates the string in some fashion. Regardless of the method, the string is not presented in cleartext. This suggests that randomizing and changing the password each time is probably not needed for most applications.

Also, is there any possibility that the relog script could be manipulated?

As long as the file's startup script is coded well and the accounts and priv's. are set up properly, there shouldn't be any way around it short of editing the binary directly and manipulating it that way. Only someone with detailed knowledge of the FileMaker binary format would be able to do that.

If you have denied admin access and are careful to avoid using global script variables (and possibly even local script variables) you should be safe from the debugging tools of FileMaker Developer or Advanced. Plus the code needs to do the right thing with respect to security when running on FileMaker 7 which lacks some of the script steps available in later versions.

Keep all of the important startup activities in the one initialization script.

# user launches the database as the auto-login underprivileged user.

Disable user abort.

Set error capture on

Enable normal user account

Re-Log as the normal user

Carry out other script steps for activities to enforce licensing or other usage restrictions

Exit script.

Edited October 14, 2009 by Guest