Transfer sensitive data in separation model

[capsprojectos]

Hi,

I would like to know your opinion about security when related with transfer sensitive data in separation models.

The full access at script level is file oriented, in result of this you can’t run a script in UI to get sensitive data in Data file, because the field should be protect from Data Viewer (no access).

I have overpass this, but I would like your opinion to learn more tools to deal with this important security scenery.

The main problem is Data Viewer, I can’t see why this should be available for non-developers users.

My clients buy FM because i sell my application to them, they don't want to use PRO or Advance. Just a Go for desktop. But for me, Data Viewer is a concern because the databases have sensitive data.

It’s rare to see Data Viewer in the topics, no one speaks about this security issue. What’s the point of having great doors with lots of padlocks, if the windows are all open.

Edited March 12, 2012 by Vaughan
Change topic title from "sensible" to "sensitive".

[Lee Smith]

Sensible or sensitive data?

[capsprojectos]

Sensible or sensitive data?

Sensitive (confidential data), sorry for my bad english.

[dansmith65]

Sensitive data should be restricted to authorized users via a Privilege Set. If that is done, then it's not an issue that a user can add a field to a data viewer, because they won't be able to see it's value if their permissions don't allow it.

[capsprojectos]

Dansmith65, it’s true.

But with separation model, you will need to use that sensitive data and you can’t use loosely because run at Full access is file oriented, so if you protect that file with no access, it’s no access for the other file (UI, for example). So you must transfer this data in other to work.

[dansmith65]

I think you may have a misunderstanding of how the separation model works, or at least at how it can work. The data does not need to be transferred to the UI file to access it, and creating a privilege set does not mean no access of the data file (unless a user who isn't authorized to view the data is logged in).

[capsprojectos]

dansmith65, I'm always available to learn new things.

I consider myself a big amateur, there lots of you with fantastic solution. They are very good, daily I find more stuff to learn.

Now back to your question, do you know Filemaker standards, these site was made by professional developers, they work with Filemaker since version 1, what do you think about this page: http://filemakerstan...eloper+layouts.

Now do you understand there are reasons to have correspondingly tables to transfer data. And you may want to compare fields like serial numbers, UI or Data version, and other things.

The serial number, license data or other developer security model to protect my money from the clients, should be without access, and I need to compare those fields in both files (Data and UI), so I think the best way is to transfer this data between both files (one direction) and do an exact calculation.

There are a lot of situations to do this for the developer and for the client.

Please remember you can’t run full access scripts for the other file.

But I agreed with you, the UI should be data free, but sometimes it’s just impossible to do that. So my question is in the air.

[dansmith65]

do you know Filemaker standards, these site was made by professional developers, they work with Filemaker since version 1, what do you think about this page: http://filemakerstan...eloper+layouts.

I like that there is a public discussion of a best practices within FileMaker; I think that's something that was missing in the FileMaker community for a while. I don't see how that relates to this topic though.

Regarding not being able to run a script with full access privileges in the UI file to get data in the Data file, I would suggest this:

Create a script in the Data file that runs with full access privileges, and takes parameter(s) to determine what data to find/compare. Then have it return a result to the calling script which can be used to determine if the comparison/action was successful.

[LaRetta]

https://fmdev.filemaker.com/thread/62775?start=15&tstart=0

I still do not see how this is an issue. Users can't see anything that they are not privileged to see.

[capsprojectos]

I will try to make things more clear.

Let’s image two FM databases related, database A with fields with non-access and database B, and you wish transfer sensitive data between both databases.

In database A, you can capture those values using a full access script, but in database B this method don’t work, because full-access isn’t for that particularly file.

So, how do you transfer non-access fields between databases.

[LaRetta]

I will try to make things more clear.

I think the discussion in the other thread makes it perfectly clear.

So, how do you transfer non-access fields between databases.

I do not transfer data between files. Everything runs (even in separation model) in the UI file. I never go to the other file at all. And I set keys only in most cases. Hey, if you are not convinced by the other thread then nothing I say in this one will convince you either. But to me, this issue is a non-concern, sorry.

and I need to compare those fields in both files (Data and UI), so I think the best way is to transfer this data between both files (one direction) and do an exact calculation.

If you begin copying data back and forth instead of letting FileMaker's relational model handle it, you will soon get out of synch.

There are a lot of situations to do this for the developer and for the client.

Really? Can you provide examples? You are hearing from Developers with a combined personal experience of more than 40 years (of working in this business full time) tell you otherwise. You rate yourself entry level and even describe yourself as 'a big amateur'. Maybe you should let it rest for awhile and then re-read it all. Many times that is what it takes for me to finally see what folks are saying.

My primary question is ... why are you working in two files? I do not mean you shouldn't HAVE two files but why are you working in them? Even with separation model, everything is handled in the UI - no script ever runs in the data file.

[capsprojectos]

Thanks LaRetta,

Yes, I describe myself as a big amateur and I’m loving it. I have no shame to declare that. I’m studding FM every day, and there is so much to learn, that I will be amateur for the rest of my life.

When I post something in the forum, it’s my point of view, my best guess. And I change option easily, when I find a better answer.

That’s why, I post this question in the forum, to learn more. To give my point of view (my concerns), and collect your options, in other to make my assumption. If I read the same post over and over, like you advised, I will get the same conclusions, because I couldn’t get my answers.

You have a clever signature “Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.” I think you did the opposite, giving full certainty about this subject.

In the last post, you said “Everything is handled in the UI - no script ever runs in the data file.” I have a different option, one of the reason, because I choose separation model was to be able to update UI constantly and for multiple clients.

So how can I preserve the accounts and passwords if a change my UI frequently, without saving passwords? With this line of thinking I must have scripts in data to manage accounts, correct?

Does you know other process to do this? Without using (FMRefesh, just native FM).

About you question, “why I’m working with two files?” I’m not working with two, but three files, two in the server and an UI file (client side). There are a lots of theories about where UI should be, but the connection will be WAN, so I choose to make this file for client side.

At the server there will be a data file (the aim is just pure data, but sometimes it isn’t possible). And other file, in this file I will be manage the UI licenses, do some test to prevent file copying (checking hostname, NIC address, and other security stuff).

It’s also important to say, the UI is opening with an account with small privileges, and all users do their login throw data file. So, to make security tight as possible, I have fields with non-access and all my testes demonstrate there wasn’t possible to transfer non-access data between files throw relationships.

Thanks for your positive option to this.

[Vaughan]

So how can I preserve the accounts and passwords if a change my UI frequently, without saving passwords? With this line of thinking I must have scripts in data to manage accounts, correct?

Ah, this is (another) instance where the separation model does not solve all problems.

There is no easy way to do it.

You are right about needing to use scripts. But I think that storing user account passwords in a table is a bad idea from a security perspective because it is possible (likely) that they will be used for other purposes.

The simplest is to use external authentication -- simplest from a database perspective, but not from an IT infrastructure perspective...

Doing it inside FMP natively:

Create an "accounts" table to store the usernames. Each account record also have a real internal FMP account with the same name (these get created and destroyed together by scripts).

Part of the update process is to import the account records from the old interface file (or maybe the existing data file, not sure) to the new file. Because passwords are not known, the update process creates accounts with the same name but with default passwords that the use must change on first log-in.

[LaRetta]

You have a clever signature “Each assumption is an educated guess, a likely condition or event, presumed known and true in the absence of absolute certainty.” I think you did the opposite, giving full certainty about this subject.

Some things in life are opinions. Some things are facts. When you cannot prove something, it is opinion until proven. Everything discussed in the link I provided has been proven. I have seen, tested and proven the results myself as well. I stand by my statements; there is no absence of absolute certainty in this situation.

No wait ... you wanted positive so ... I positively stand by my statements. Re-read it all again, use the system, try things ... that is how we all learn. And you can discover things we do not know and share them with us. But please do not try to use my words against me because I'll positively disappear into vapor! :yep:

[capsprojectos]

Thanks Vaughan,

Saving passwords is out of question! I think no one saves passwords , Steve Blackwell repeats the same advice constantly.

You gave me a good idea, to import the account names, creating a random password, and let user to change their passwords.

I have a method to prevent “easy passwords” like 12345, easy names or other unsafe passwords. Do you know any method to prevent users, to repeat the same password over and over. In my application all users should change his password in a 6 month period, but how I can prevent to be a different password.

There are developers using encrypt process in scripts or in custom functions without saving the true password at field level, do you think it’s save to create this method?

The plugins are more secure than FM? I’m using a encrypt dll to secure some sensitive data (fingerprints) throw dotnet, do you think it’s more secure to protect passwords using a plugin for scriptmaster with my own encrypt (without using a AES …) or it's just a bad idea.

[capsprojectos]

LaRetta,

Are you talking about that link? First I’m not the author of that post, second I have the right to my option, and in my point of view there no point of current tab (dataviewer) not use a password like developers have to use, to do a debug.

In my case, I must have a secured database, to see the name of tables, fields, to be able to change fields (it’s impossible to make all fields as non-access, too much work and it isn’t easy to do this in separation model) so for me, the current tab should be only for developers.

And in the other hand, if you want to make your point please do in the other forum, to make even more rich for the other users.

I request positive, because I think no one learn with negative speeches.

[Vaughan]

Thanks Vaughan,

Saving passwords is out of question! I think no one saves passwords , Steve Blackwell repeats the same advice constantly.

You gave me a good idea, to import the account names, creating a random password, and let user to change their passwords.

I have a method to prevent “easy passwords” like 12345, easy names or other unsafe passwords. Do you know any method to prevent users, to repeat the same password over and over. In my application all users should change his password in a 6 month period, but how I can prevent to be a different password.

There are developers using encrypt process in scripts or in custom functions without saving the true password at field level, do you think it’s save to create this method?

The plugins are more secure than FM? I’m using a encrypt dll to secure some sensitive data (fingerprints) throw dotnet, do you think it’s more secure to protect passwords using a plugin for scriptmaster with my own encrypt (without using a AES …) or it's just a bad idea.

No no no not a random password... How will anyone be able to login the first time?

If you need serious password management then switch to external authentication. The AD or OD will enforce the password restrictions outside of FMP.

[FMDuck]

capsprojectos,

I think you may be confusing issues of the Data Separation Model with general security issues. I'm not too up to speed myself on the DSM (as my next post will show) but I do have a solution that I sell which has the security very tightly wrapped. It sounds like your issues are because you have a solution that you sell and you don't have control over it after selling it.

There are many points to answer your questions about security in FMP but here are a few to consider: (all this assumes that this is a 'shrink-wrap' solution)

- Be sure to remove the [Full Access] privileges before distributing it.

- To be able to provide updates to your solution, you have no choice but to work around FMP's security. I wouldn't buy software that made everyone in my company recreate a password every time there was an update and you can't require that with your FMP solution either. Consider creating a user table and using something like DataVault Maker and create a hash for passwords for users.

- Have one FM account and privilege set that is only used for an automatic login. Duplicate the password for that account in a custom function. In the script that runs on startup, first, verify that the user is not using FMP Advanced and if they are, give them an error message saying they must use FMPro then log them out immediately. After that, perform a re-login using the account I just mentioned and pull the password from the custom function. If an error occurs, then the user tried to hack the solution. At that point, I completely and permanently lock the solution and close FMP.

- The third and last step (actually 5th because you should start by turning on error capture and turning off user abort) in that script is call a subscript that has all of your 'real' launch script steps. When you call the subscript, use a script parameter of a custom function that simply includes any random string of text. In the subscript, start by checking the script parameter and making sure it matches. If not then close the file.

- Early in that second script, have another automatic (without dialog) re-login script step using an account that allows all your startup scripts, layouts, fields, etc to be accessed but not your core solution.

- After any required startup script steps are run, provide the user with a dialog box to login, then validate their password using the hash data stored in the User table. ALL your validation and any keys or passwords should be stored in custom functions and ALL your custom functions should be set to require full access privs to view (the custom functions will all work with any privilege set)

- After validating the user and password in the user table, relogin again (without dialog) using a third privilege set and again, getting the password from a custom function. then you can continue on from there. This third privilege set should allow all the necessary user interaction.

I know this is fairly cursory but it's an overview of what's required to assure none of your system is visible*. What else you do depends on the scope of your solution, license control, hosting methods and who knows what else.

* (the dreaded asterisk) As I understand it, a savvy user can still see and run your scripts. You can secure any sensitive scripts by always calling them with a script parameter and then checking it early in the script. If it doesn't match then you can kill the script.

Attached are 1) my accounts, 2) my startup and shutdown scripts and 3) the very first script that runs on File Open (I'm using FMP11)

HTH.