My two cents. If someone has the permissions to run a DDR, then they also have permissions to read all your scripts and edit all your external data sources...so they already have access to all the data you want to hide in the DDR, and hiding that data from the DDR does us all a disservice.
Normally, in a secure system, even FileMaker, not even administrator accounts can see passwords. For that matter, you usually can't even see your own password. There are at least a few good security reasons for this limitation.
It only makes sense that the DDR would be consistent with this FileMaker Pro security policy, and even be consistent with the DDR's handling of passwords in every other section of the report.
Where's shblackwell when we need him?
Thank you for your post and comments.
I understand your side as well as "hschlossberg". I have sent both set of comments to our Development department for a complete explanation. When I receive a reply, I will let you know.
The Dynamic Database Report is only available for the account with [Full Access] privilege. If the user has permission to run the DDR, they can then access the password in Manage External Data Source dialog. Although it may seem like a "security" issue, the DDR is often used for archival documentation, so obscuring the passwords could then be considered "data loss" in that scenario.
Then shouldn't the same argument apply to where passwords could have appeared in the Account and Script sections of the report? And yet they do not show or are obscured in those places.
And yet the password stored for an ODBC source is likely to be just as private and privileged as any other password, if not more so. In fact, those with full access to the file should not necessarily be able to know any passwords in the file (except their own).
The following policy is good policy for all passwords not just local account passwords: "Passwords are stored using a one-way hash, meaning the password can be encrypted but never decrypted. Therefore, it is only possible to reset a password, not recover a password."
Developers, customers, external system administrators, and information security officers all want to trust that FileMaker is securing all passwords with equal or greater care—and is not arbitrarily careless with some passwords and not others.
By the way, the security guides should be updated to warn that the following is not true in all cases:
I understand that passwords to external systems can't be one-way hash, because they at least have to be decrypted so that FileMaker can submit them to other systems.
Nevertheless, the best FileMaker could do is keep that password encrypted and hidden from eyes and only decrypt it to send it to other systems and not for any other purpose.
And we would expect FileMaker to do the best it could.
You are confusing two totally separate things.
All FileMaker account passwords ARE stored as a one-way hash. You cannot go into FileMaker's security settings or anywhere else and be able to retrieve account passwords.
Passwords included as part of scripts or in external non-FM data sources are never encrypted and there is no pretense that it is. If you have full access privileges on an FM database, you can open the 'Edit Data Source' window for ODBC and plainly see the password right there. The same goes for the ODBC script step, Send Mail script step, and probably others as well.
+ 1 and if you have full access, you can change (or delete) any password in FM Security. But you cannot reveal it. So DDR follows that.
I'm not confusing anything. As stated in my previous reply, I know those passwords are two separate things, but they are not two totally different things—they are both passwords, and they can both grant access to sensitive data.
If you have full access privileges on an FM database, you can open the 'Edit Data Source' window for ODBC and plainly see the password right there. The same goes for the ODBC script step, Send Mail script step, and probably others as well.
Also unwise security implementation.
Except the same does NOT go for ODBC Import Script steps; you can not see nor copy the password in the Import Records script step.
The other big difference between FileMaker exposing a password in a FileMaker Pro file and exposing it in the text output file of a DDR, as you already pointed out, is that the passwords in a FileMaker Pro file can still be relatively protected by a Full-Access account; there are no such possible protections on a mere text DDR file, especially a text file that has left whatever protections were on the server where those passwords resided.