The golden master version of iOS 7 is out. This is not a beta issue anymore. Considering that everyone involved knew about this issue month ago this is very disheartening. Get(SystemNICAdress) is also affected. This signales the end of any serious development of professional FileMaker apps for iOS.
Looks like my auto log-in scheme, which works wonderfully and is pretty secure, will be obsolete the minute a client installs iOS 7. It would be nice to know when an update fix for FM Go 12 will be available, or if one is even pending.
If I can't determine what device is logging into my solution (and I start asking clients to use a name-password,) then there will certainly be people handing out credentials, and I can't do a thing about it.
From my limited knowledge Get(PersistentID) is Filemaker's own generated ID and not an ID burned into the CPU, ROM or elsewhere. The fact that Windows and Mac delivers two different ids, as reported elsewhere, if run on the same computer raises a big issue anyway. And swap a component...
Personaly I feel that many of Filemaker's get(x) are in need of updating.
A little cookie may be better.
Not true at all...
There's so much other info you can grab even to the names of all of the files in the documents folder.
A design is very weak and subject to future problems if it does not use Accounts and Preferences.
I use accounts and privs for every user. The client doesn't even know their account name and password because the startup script determines it for them.
My current scheme is much stronger than handing out names and passwords. I'm guessing you haven't used such a sign-in method. The solution is well protected -- and never asks for credentials, because I can (used to be able to) identify the device.
Unfortunately it is true...you will find more info about the Get(PersistenID) in the thread referenced by the orignal poster including how FileMaker generates it. A cookie is the easiest protection to circumvent.
I am assuming that your script verifies the Persistent ID and then resets the account name and password via your script. Nice and easy.
So, how exactly do you determine if the Filemaker file is being opened by someone other than the account holder. Say, that person goes to lunch and the 'villain' then opens the Filemaker file on that computer?
The issue isn't how much data you can grab, it it how much unique data you can grab off the iPad. Beside the SystemNicAddress and the Persistent Id what other unique data can you grab?
Although extremely rare, someone could open the file if the screen saver doesn't kick in.
I have the added benefit that all reporting data is read only, so the only possible damage that could be done by a villian is they could change parameters on reports for that user. The solution is secure when hosted, and monthly downloads of the entire file are available -- obviously downloaded copies will work only with the assigned computers, so even they cannot be shared with others.
Elegant, tested, secure, and clients love that they don't need to know one more set of credentials. I love that it is impossible to cheat the programmer.
I'll take the villain rarity (has not happened yet) over the assured theft of use if I used names and passwords.
l also have played a bit with these ideas and I use the persistent to
insure the computer id, etc.
The big problem is spoofiing and from what I've read almost everything can
If this is just for one small company with unimportant data, no problem.
But for HIPAA or for large corporations, this might not be acceptable since
account names and passwords are requiredd to be entered by the user. Then
you can run all of the get(checks) you want.
A windows IT guy will issue one account name and password that opens
everything, including FIlemaker. I am running up against this so I am also
doing my own Firewall in Filemaker.
I assume you are using SSL encryption between client and server?
I don't believe you can spoof the persistent ID, but even so I really don't have clients that ar capable (I'd wager their IT staffs aren't capable of spoofing a NIC address.)
My current log-in solution is perfect for what I am doing. No HIPAA compliance needs. Certainly no need for SSL. No second-party IT to deal with. Just ad-hoc reporting anincredibly large amount of sales data available to many users across several companies. It really sounds like what is perfect for my needs isn't going to work for you. Losing the use of a persistent ID is terrible for me and others, but it sounds like you really can't use this method for whatever it is you're doing.
Besides, how are you going to spoof a valid persistent ID when you don't even know any other IDs? How could a user possibly know what method I am using since they never see a name or a password? If you somehow knew I was using a persistent ID (which none of my users do), then the villian must know how to use FMP to obtain the persistent ID and then...
At that point, you may as well call a valid user and ask them to run the report and send it to you. This method isn't for everyone, just an elegant method for many.
Actually I do use the persistent id after the account name and password
have been entered. Account names and passwords are notoriously unreliable
as people put them on postit notes on their walls and share them with
others. Plus multiple people can log in at the same time using the same
account name. So, I also add multiple layers of security using Persistent,
NIC, monitor size, and other bits of information. I have also devised a
cookie method of saving a small anonymous file somewhere on their drive and
if it is not there or any of the other info fails, I close the application.
The NIC is important to me to determine location, if it is not the local
network, bye bye.
I'm also working on determining if two people are using the same password
and if the password doesn't match the computer.
Filemaker Server will close an accounts connection, if the setting is made,
after a period of inactivity. If I only used the Persistent ID method as
you use it, then anyone could sit down at a computer while that person is
at lunch and log into their account. So, from my point of view, you aren't
protecting the database and this method isn't acceptable in many
environements. Wny use account names and passwords?
What about the esc key? Today's computers are fast enough that it is difficult to get this to interrupt the startup script but older computers were easily victimized by this.
You do have the first step in your startup script to disallow the esc key abort sequence?
"What about the esc key?"
How does that even apply to iOS devices?