In the really old days before the Internet and security problems, we'd link to one of our solution files and not think anything about that since that was the way it works.
Now we put many, many tables inside one file and think that since we have accounts and passwords, etc. that the file is secure. And with the little checkbox in 14, I thought they would now be. I assumed that the checkbox shown would mean that you would have to have the same account name and password to link to my file when this box is checked. Sadly, you do not.
All this checkbox does is require that the unwanted linker with any old full access account click a button to accomplish what they used to do without this checkbox.
Note; hacker is a brand new file with just the admin account as created by FileMaker. When I create a new TO and point to the file, this dialog opens. So, by creating a new TO in a new file, I now have full access to all of the tables in the file and all of the scripts.
Disclaimer: this test is being run locally and the file is not protected with the encrypt when not open capability of Advanced. It does however have accounts and passwords and was tested both open and closed. I don't have a server to check this on a remotely hosted file but will next week. So, for the time being the limits are that these are local files on my drive.
Having checked the box and feeling safe and secure, I closed the file and opened a brand new file which I named Hacker just for the heck of it.
I left it in a pristine state so that the Admin account was active and then I opened the design environment and created a new To and pointed it at my file. Bingo, Do you want to open this with Full Access. Yes, and there was the TO to my supposedly safe file and I could create TOs to every file and even import scripts using a plain, new file.
I used this technique to bypass the protection of the 2 Factor demo file and once I had created the TOs I simply replaced all of the Persitent IDs with my own and now I could walk right in. Took five minutes to think it through. Granted it wasn't a secure file but a demo file.
It might be interesting to test this on one of the encrypted 'safe' files created with Avanced since the encryption may not be of the entire file but just a new password. IF the file isn't really encrypted, then it might be possible to do this on a copy.
Of course this is old stuff and everyone will tell you to protect your backups for just this reason. No one needs an account name and password to access the data and import scripts just a full access account in any file. A quite serious flaw isn't it... Every old FileMaker file is potentially open to every user in the world if they can get next to it.
Of course, remotely logging into the file on a server will require an account name and password. So what happens if you create a new file and that account name and password and give it full access privileges rather than read/write. Can you now do what I did since you have access? You are fully vetted with your credentials but now you are outside the box. Is this so?
This isn't just a FileMaker problem, its applicable to almost all databases and guess what, those big data files aren't as secure as FileMaker data is as they may be little more than a text file with no protection. dBase files can be read by a text editor or one of hundreds of small apps that read xbase files.
Years ago I could use Word and open the FileMaker file and with a little effort begin grabbing bits of data. It was easier with an xBase file since the data all lined up in fixed lengths. Then FileMaker did something to the data and the visual text disappeared so that method didn't work. But what I've described above was even better and easier.
14 closes a few holes but there are thousands of files out there that use the old technology and are wide open...