It's frightening, really.
I sympathise about the lost password when it is an honest error. I would love for FMI to be offering this service. I've had a number of client over the years who have locked themselves out because of change of staff.
But out there on the web for anyone to use is not a good thing.
One hopes that we have not now alerted the unscrupulous kind. I am sure they are not in this community though. ;-)
I think that to take someone elses' work and try to disguise it as your own would be extremely difficult for anyone who hasn't the skill to build it for themselves. We all do it differently and trying to follow someone elses logic could be a real challenge... The community is very aware of techniques and design that would give them away...
FileMaker Inc. even used to recover passwords for you for a fee. There are some other hacks out there that will get that hash back for you too. But they do introduce potential problems and be aware that these recoveries can sometimes introduce corruption of the file. I have used these programs before for clients, but only used it on a copy. Also, if ethical, you will do what youcan to verify this database really belongs to the client and isn't stolen data. The program I used didn't create a new admin, just revealed the password. The reality is that FileMaker is as secure as any other database, but that means you do not ever loose physical control of the file or let others have OS level access or programs like these can be run against them. Many databases are eve stored in the clear and just a text or hex editor can show the content. Access via a client/web/ODBC will never allow this to happen. There is a white paper on FileMaker security in the technical section if you are interested. And while there are several password breaking programs like this for fp7, fmp12 is a whole new format and may take time for the hackers to break. Just remember security means physical security and security against OS level attacks and you'll be just fine. FileMaker is really one of the most secure databases out there and even NIST only a few vulnerabilities identified and those went back to version 6 and before.
I agree partially.
First here we have issue of unallowed access to data and second to know-how of developer. For first I agree that you can solve it by physical security but what about second? Customers usually have acess to the database so there is no way to prohibit them to see how you write your code etc…
I look at the problem from developers perspective.
I would look at it from the perspective of copyright law. You as a developer are owner of the code (or if you are in-house developer, it's usually the company or the institution that has the rights for the code) and can decide how to license it to users (open source, payware, annual license, whatever ...).
AFAIK, US copyright law prohibits to disassemble software, and you can base on that if you find out that a customer has violated it.
In Switzerland, copyright law is less strict: Disassembly of parts of the software is allowed if you need specific knowledge about the software for the purpose to create an interface to other software.
(Side comment: As long as account and password are stored in the .fp file structure, there will be always tools which are able to remove the entire lock. So no need to find out the key. As a consequence, hosted solutions that stay at the developer will offer the greatest security.)
Copyright does not help you if you do not know what is happening behind your back and this is usually the case.
If you're relying on technology to solve the problem of theft, good luck. People have been trying to do that for millennia.
I didn't say anything different, if you had read carefully my post. Of course, the old saying "nullum ius sine actione" holds.
There are two options with regards to technical measures:
- when you create a runtime, you can remove Admin access from files permanently in the Developer Utilities.
- you host the solution and offer it as a service.