Security Question

[HBMarlowe]

I can prevent an account from accessing a given field, but is it possible to prohibit a table or field from being imported into another FM file? Sensitive data is stored in my FM solution and i can't be absolutely certain that another user of the computer will not copy my file and import my tables and records thereby gaining access to my data.

 

Thanks in advance for your help.

 

John

[AHunter3]

You can turn off exporting privileges on the Privilege Set that you've associated with their account. Accounts that can't export can't be imported from.

 

(That doesn't mean they won't possibly go after your solution with a crowbar. There are password crackers out there, I'm afraid)

[Maarten Witberg]

Further to that...

 

You state in your profile that you work on both platforms...

I don't know about windows, but on a mac I'd sure work with separate user accounts if more users work with the same computer and sensitive data is stored on that computer's harddisk. A file that is not stored in a shared folder can only be seen and accessed by the user that has the right login and password at system level. At network level, it is possible to define shared volumes and link them to certain users or user groups. I can't imagine that a thing like that can't be set up in windows as well.

 

Maarten

[AHunter3]

You could put the solution on a dedicated server that serves the file up as Host, and have the users only open it as a guest. Then they can't copy your solution at all (you can't "Save a Copy" when you're the guest of a hosted file), as long as you have file sharing turned off on the host box (which you should anyway for other reasons).

 

Password crackers that I've run across or heard described by others seem to all need file-level access to the database they're cracking (i.e., you can't tell the password cracker to open fm7://192.168.3.27/Filename.fp7, they don't speak FileMaker's native networking protocol, you have to navigate to the file as seen in a normal Open File dialog that lacks a "Hosts" button).

 

Then all you need do is turn off exporting privs and at that point all you have to worry about is them printing all your data out and acquiring it that way.

[Robert Schaub]

You can turn off exporting privileges on the Privilege Set that you've associated with their account. Accounts that can't export can't be imported from.

 

Allan is right here. Turning off export privledge will prevent this.

Turning of field access can cuase problems and give false results.

If a field relies on a calculation and it access is turned off, the result maybe

wrong because it is not factoring in the field not accessable.

 

(That doesn't mean they won't possibly go after your solution with a crowbar. There are password crackers out there, I'm afraid)

 

password crackers?

 

If HBMarlowe is developing in 8.5 Advanced, I think? the so called "password crackers" will not work.

[J Wenmeekers]

If a field relies on a calculation and it access is turned off, the result maybe

wrong because it is not factoring in the field not accessable.

 

Not only a calculation, also when you restrict the access with a PrivilegeSet in Accounts & Privileges.

 

FileMaker will consider non accessible related fields (the data) as null.

 

Furthermore, you will have no allert that FileMaker can't access the data in a needed field.

 

There 's a workaround but it's cumbersome and always open for errors.

[AHunter3]

password crackers?

 

If HBMarlowe is developing in 8.5 Advanced, I think? the so called "password crackers" will not work.

 

Well, if Full Access privs have been ripped out, no password cracker is going to restore it. That file simply can't ever again be modified in terms of its structure.

 

But if a username/password combo that has Full Access still exists (and developing under Advanced doesn't change that intrinsically, does it?), I'd think it would still be as much at risk of password-cracking as a solution developed under plain-vanilla FmPro 8.5. I could be wrong.

[HBMarlowe]

Thanks to all for your thoughtful replies. It remains that controlling access to the original file and backups is essential!

 

John