Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.filemaker > #2242 > unrolled thread
| Started by | clkaufmann@gmx.ch (Christoph Kaufmann) |
|---|---|
| First post | 2015-04-30 09:49 +0200 |
| Last post | 2015-04-30 09:07 -0700 |
| Articles | 12 — 6 participants |
Back to article view | Back to comp.databases.filemaker
How to prevent a developer from tampering with the log clkaufmann@gmx.ch (Christoph Kaufmann) - 2015-04-30 09:49 +0200
Re: How to prevent a developer from tampering with the log Ursus <ursus.kirk@ziggo.nl> - 2015-04-30 10:04 +0200
Re: How to prevent a developer from tampering with the log clkaufmann@gmx.ch (Christoph Kaufmann) - 2015-04-30 10:54 +0200
Re: How to prevent a developer from tampering with the log Martin Τrautmann <t-usenet@gmx.net> - 2015-04-30 09:22 +0000
Re: How to prevent a developer from tampering with the log clkaufmann@gmx.ch (Christoph Kaufmann) - 2015-04-30 19:59 +0200
Re: How to prevent a developer from tampering with the log Helpful Harry <HelpfulHarry@BusyWorking.com> - 2015-05-01 09:12 +1200
Re: How to prevent a developer from tampering with the log Ursus <ursus.kirk@ziggo.nl> - 2015-04-30 11:36 +0200
Re: How to prevent a developer from tampering with the log clkaufmann@gmx.ch (Christoph Kaufmann) - 2015-04-30 19:59 +0200
Re: How to prevent a developer from tampering with the log ursus <ursus.kirk@gmail.com> - 2015-04-30 21:16 +0200
Re: How to prevent a developer from tampering with the log Martin Τrautmann <t-usenet@gmx.net> - 2015-04-30 20:19 +0000
Re: How to prevent a developer from tampering with the log Helpful Harry <HelpfulHarry@BusyWorking.com> - 2015-05-01 09:17 +1200
Re: How to prevent a developer from tampering with the log Howard Schlossberg <howard@nospam.fmprosolutions.com> - 2015-04-30 09:07 -0700
| From | clkaufmann@gmx.ch (Christoph Kaufmann) |
|---|---|
| Date | 2015-04-30 09:49 +0200 |
| Subject | How to prevent a developer from tampering with the log |
| Message-ID | <1m3oqe3.130zxj910odzpeN%clkaufmann@gmx.ch> |
FMP 11/FMS 11 on Win 7: Users create entries in a list an write into fields. Problem: the solution and its output are only accepted if there is no way for the company to alter entries without trace, i.e. change creation/modification timestamps etc. While there a tools like ultralog, auto-enter, prohibit entries by users, they all depend on restricted access. Here's the catch: The solution is created and maintained by an in house developer. Imagine this conversation: Company: the log shows that we saw this/did that on... Business partner: your admin could have changed the timestamps and the text fields, in fact, he could have created this record 30 minutes ago. Compnay: No he couldn't have because [insert solution to this problem here] I assume I could write logs into csv files or something, that'll give a file on the hard drive with a creation date etc. But is this file info safe? -- Christoph Kaufmann http://clk.ch
[toc] | [next] | [standalone]
| From | Ursus <ursus.kirk@ziggo.nl> |
|---|---|
| Date | 2015-04-30 10:04 +0200 |
| Message-ID | <c1789$5541e206$52d9780b$48789@news.ziggo.nl> |
| In reply to | #2242 |
Christoph Kaufmann schreef op 30-4-2015 om 09:49: > FMP 11/FMS 11 on Win 7: Users create entries in a list an write into > fields. > > Problem: the solution and its output are only accepted if there is no > way for the company to alter entries without trace, i.e. change > creation/modification timestamps etc. > > While there a tools like ultralog, auto-enter, prohibit entries by > users, they all depend on restricted access. > > Here's the catch: The solution is created and maintained by an in house > developer. > > Imagine this conversation: > > Company: the log shows that we saw this/did that on... > > Business partner: your admin could have changed the timestamps and the > text fields, in fact, he could have created this record 30 minutes ago. > > Compnay: No he couldn't have because [insert solution to this problem > here] > > I assume I could write logs into csv files or something, that'll give a > file on the hard drive with a creation date etc. But is this file info > safe? > If there is no trust between company and developer they shouldn't have hired him/her in the first place. Why would a developer change a records timestamp? Other then for fraudulent uses? No log system, however carefully constructed is a 100% safe. If a log-file resides on a certain computer, you only need access to that computer. A developer might need that access. If this is really an issue then you could let the solution send an e-mail to the company after every change. Or buy an encryption-plug in that garbles the log. But I probably would doubt my position as a developer and look elsewhere for a job. keep well, Ursus
[toc] | [prev] | [next] | [standalone]
| From | clkaufmann@gmx.ch (Christoph Kaufmann) |
|---|---|
| Date | 2015-04-30 10:54 +0200 |
| Message-ID | <1m3ot4f.vsa6rg1pb16gwN%clkaufmann@gmx.ch> |
| In reply to | #2243 |
Ursus <ursus.kirk@ziggo.nl> wrote: > If there is no trust between company and developer The company and the developer are on the same side; the developer is an employee. That's exactly the problem. The company is a hospital that provides nursing. Insurances pay the nursing and check the documentation. > Why would a developer change a records > timestamp? Other then for fraudulent uses? Because some insurance person made an appointment to check the documentation. Chief nurse rushes to the developer and says: we did a lot of nursing nobody documented because there was no time and a flu epidemy, could we please put in the missing records with the date and time of our work, not the ones of record creation? That's not lying after all, but the insurance guy gets the wrong impression and the hospital is about to lose a lot of money. We don't need to discuss what kind of developer would be tempted or get instructed to do this. As long as this is technically possible, the insurance must and will not accept the documentation and all the work will count as undocumented, i.e. not done. A third party product makes sure the client can't change the timestamp. I need a tool for the same feature in my in house Filemaker solution. > If a > log-file resides on a certain computer, you only need access to that > computer. A developer might need that access. That's interesting - we're using a data center, they could move the log files to some sort of trust center. > If this is really an issue It is. It's about money :-) > Or buy an encryption-plug in that garbles the log. Plugin is in place. How would a check look like? -- Christoph Kaufmann http://clk.ch
[toc] | [prev] | [next] | [standalone]
| From | Martin Τrautmann <t-usenet@gmx.net> |
|---|---|
| Date | 2015-04-30 09:22 +0000 |
| Message-ID | <slrnmk3t21.1gs8.t-usenet@ID-685.user.individual.de> |
| In reply to | #2244 |
On Thu, 30 Apr 2015 10:54:21 +0200, Christoph Kaufmann wrote: > A third party product makes sure the client can't change the timestamp. > I need a tool for the same feature in my in house Filemaker solution. You can't do that in FMP. Of course you might prevent data entry via layouts and record options. But all of this can be bypassed by someone with admin privileges. You could use an external tool which does prevent manipulation via data entry - such as simple text files with timestamp of data entry and checksum calculation. You can import those values to FMP and do the processing as required within FMP. - Martin
[toc] | [prev] | [next] | [standalone]
| From | clkaufmann@gmx.ch (Christoph Kaufmann) |
|---|---|
| Date | 2015-04-30 19:59 +0200 |
| Message-ID | <1m3pj3i.1hyo77c10392okN%clkaufmann@gmx.ch> |
| In reply to | #2245 |
Martin ?rautmann <t-usenet@gmx.net> wrote: > You could use an external tool which does prevent manipulation via data > entry - such as simple text files with timestamp of data entry and > checksum calculation. We'd have to make sure the text wasn't created later in the process. What about the Filemaker backup file? It's file info says when it was created. -- Christoph Kaufmann http://clk.ch
[toc] | [prev] | [next] | [standalone]
| From | Helpful Harry <HelpfulHarry@BusyWorking.com> |
|---|---|
| Date | 2015-05-01 09:12 +1200 |
| Message-ID | <010520150912058370%HelpfulHarry@BusyWorking.com> |
| In reply to | #2245 |
In article <slrnmk3t21.1gs8.t-usenet@ID-685.user.individual.de>, Martin ?rautmann <t-usenet@gmx.net> wrote: > On Thu, 30 Apr 2015 10:54:21 +0200, Christoph Kaufmann wrote: > > A third party product makes sure the client can't change the timestamp. > > I need a tool for the same feature in my in house Filemaker solution. > > You can't do that in FMP. [snip] I doubt you can do it in anything. The developer is the one making the system, so, by necessity, they always have access to everything. Helpful Harry :o)
[toc] | [prev] | [next] | [standalone]
| From | Ursus <ursus.kirk@ziggo.nl> |
|---|---|
| Date | 2015-04-30 11:36 +0200 |
| Message-ID | <11259$5541f7a4$52d9780b$36548@news.ziggo.nl> |
| In reply to | #2244 |
Christoph Kaufmann schreef op 30-4-2015 om 10:54: > Ursus <ursus.kirk@ziggo.nl> wrote: > >> If there is no trust between company and developer > > The company and the developer are on the same side; the developer is an > employee. That's exactly the problem. The company is a hospital that > provides nursing. Insurances pay the nursing and check the > documentation. > >> Why would a developer change a records >> timestamp? Other then for fraudulent uses? > > Because some insurance person made an appointment to check the > documentation. Chief nurse rushes to the developer and says: we did a > lot of nursing nobody documented because there was no time and a flu > epidemy, could we please put in the missing records with the date and > time of our work, not the ones of record creation? That's not lying > after all, but the insurance guy gets the wrong impression and the > hospital is about to lose a lot of money. > > We don't need to discuss what kind of developer would be tempted or get > instructed to do this. As long as this is technically possible, the > insurance must and will not accept the documentation and all the work > will count as undocumented, i.e. not done. > > A third party product makes sure the client can't change the timestamp. > I need a tool for the same feature in my in house Filemaker solution. > >> If a >> log-file resides on a certain computer, you only need access to that >> computer. A developer might need that access. > > That's interesting - we're using a data center, they could move the log > files to some sort of trust center. > >> If this is really an issue > > It is. It's about money :-) > >> Or buy an encryption-plug in that garbles the log. > > Plugin is in place. How would a check look like? > OK I see where you are going now. Ofcourse you need to save a log NOT in the same folder as the filemaker files. Even better not even on the same computer. Set up an encrypted partition on a different server. Create an email account on that, such that filemaker can send an email to the server where the logfile gets encryted and stored. Developer doesn't need access to that, so he doesn't need any password. His supervisor would be the one with access. AND create a double check on an offline account (Cloud-service) Evernote isn't too expensive and can be set up easily by the supervisor. Supervisor would be the only one accessing. Evernote creates an email address and it could very easily be done such that filemaker sends a copy to evernote. Using the hashtag system mails also get classified into groups if needed. Then I would create one line of MD5 code for the whole record for every committed change within the filemaker file, based on timestamp and contents. Store the MD5 within the filemaker file AND within both logs. MD5 is harder to read, but also very hard to crack. This would ofcourse create an enormous amount of data, even with one line for every change. And the supervisor would need to verify the filemaker data against the log files, which is an enormous amount of work. But could be done by a very simple filemaker application importing a newly created MD5 for the file and from the log, then comparing them. The generated MD5 from filemaker should equal the last stored within the log. Also be aware that, if dedicated to the task, any system can be cracked. Ursus
[toc] | [prev] | [next] | [standalone]
| From | clkaufmann@gmx.ch (Christoph Kaufmann) |
|---|---|
| Date | 2015-04-30 19:59 +0200 |
| Message-ID | <1m3pjb3.1xg9ghk1stto8wN%clkaufmann@gmx.ch> |
| In reply to | #2246 |
Ursus <ursus.kirk@ziggo.nl> wrote: > Of course you need to save a log NOT in > the same folder as the filemaker files. Even better not even on the same > computer. Thanks for the details, I understand the process now. We'd have to move the log files out of our own company's reach. Question: if I click on any file on a disk and press Cmd-I (File/Properties on Windows), I get a created/modified info from the OS - can this be manipulated, too? -- Christoph Kaufmann http://clk.ch
[toc] | [prev] | [next] | [standalone]
| From | ursus <ursus.kirk@gmail.com> |
|---|---|
| Date | 2015-04-30 21:16 +0200 |
| Message-ID | <mhtuvr$4vr$1@dont-email.me> |
| In reply to | #2265 |
Christoph Kaufmann schreef op 30-4-2015 om 19:59: > Ursus <ursus.kirk@ziggo.nl> wrote: > >> Of course you need to save a log NOT in >> the same folder as the filemaker files. Even better not even on the same >> computer. > > Thanks for the details, I understand the process now. We'd have to move > the log files out of our own company's reach. > > Question: if I click on any file on a disk and press Cmd-I > (File/Properties on Windows), I get a created/modified info from the OS > - can this be manipulated, too? > You could change it, if really set to it, if needed you could include MD5 of timestamp at closure of the file. But this would be difficult and the moment the file is opened this would be reset to current date and time. Altering creation or modification stamps of a file would serve no purpose. The contents of a file governs its validity, not its timestamp. A false timestamp could also prove an error within system setup. Or a glitch in time-management. It wouldn't prove any wrong doing. -- Keep well, Ursus
[toc] | [prev] | [next] | [standalone]
| From | Martin Τrautmann <t-usenet@gmx.net> |
|---|---|
| Date | 2015-04-30 20:19 +0000 |
| Message-ID | <slrnmk53ig.1gs8.t-usenet@ID-685.user.individual.de> |
| In reply to | #2265 |
On Thu, 30 Apr 2015 19:59:36 +0200, Christoph Kaufmann wrote: > Question: if I click on any file on a disk and press Cmd-I > (File/Properties on Windows), I get a created/modified info from the OS > - can this be manipulated, too? yes
[toc] | [prev] | [next] | [standalone]
| From | Helpful Harry <HelpfulHarry@BusyWorking.com> |
|---|---|
| Date | 2015-05-01 09:17 +1200 |
| Message-ID | <010520150917197253%HelpfulHarry@BusyWorking.com> |
| In reply to | #2265 |
In article <1m3pjb3.1xg9ghk1stto8wN%clkaufmann@gmx.ch>, Christoph Kaufmann <clkaufmann@gmx.ch> wrote: > Ursus <ursus.kirk@ziggo.nl> wrote: > > > > Of course you need to save a log NOT in > > the same folder as the filemaker files. Even better not even on the same > > computer. > > Thanks for the details, I understand the process now. We'd have to move > the log files out of our own company's reach. > > Question: if I click on any file on a disk and press Cmd-I > (File/Properties on Windows), I get a created/modified info from the OS > - can this be manipulated, too? Easy. Change the computer's system date before the file is created / modified. If it is a log file, then it will have probably have dates in it, so the dates would be in an incorrect order ... except someone can easily modify the log file. Helpful Harry :o)
[toc] | [prev] | [next] | [standalone]
| From | Howard Schlossberg <howard@nospam.fmprosolutions.com> |
|---|---|
| Date | 2015-04-30 09:07 -0700 |
| Message-ID | <mhtjuq$khu$2@news.motzarella.org> |
| In reply to | #2242 |
On 4/30/2015 12:49 AM, Christoph Kaufmann wrote: > FMP 11/FMS 11 on Win 7: Users create entries in a list an write into > fields. > > Business partner: your admin could have changed the timestamps and the > text fields, in fact, he could have created this record 30 minutes ago. As others have said, nothing is going to be 100% defensible if you have people administering the system who might have some conflict of interest (real or imagined) with one of the parties. My suggestion would be to say to those questioning it: you can set up your own SQL database with your own administrators on your own servers, give us privileges to INSERT but not UPDATE (i.e. add records but not edit existing records) and then we will set up FileMaker to write to your SQL log each time something is changed or added on our end. Given that, even if your FM admin temporarily turns off the SQL logging component to "fake" some FM data, the other party still has a log of what the data originally was. Howard
[toc] | [prev] | [standalone]
Back to top | Article view | comp.databases.filemaker
csiph-web