views:

66

answers:

2

What are the key features should I consider if I want to create a simple fraud proof and non repudiation system? For this question, I am mainly concentrating on the integrity of the database rows. This is not a security permission question.

Using a soccer database as an example, some of the key features that I would implement are:

  1. Prevent DBA from modifying the row data using traditional SQL. For example, if the database row has already stored 2:1 as the result, if DBA changed the result to 2:3, we should be able to detect the modification. All changes should be done via the main application.

  2. Prevent the copying of a row of the data to another row from using the backend changes. We should be able to detect the fraud changes.

Are there any other issues or features I should consider to make my system more fraud proof? What are the best practices that I should be aware of? Any pointers would be most appreciated.

Many thanks in advance.

+2  A: 

Create one column which is a cryptographic signature of the other columns. So long as the ID is included in the signature computation, you couldn't copy a row because the ID would change. No modifications could be performed without recomputing the hash, so the DBA's change would be detectable too.

That doesn't tackle the problem of DBAs removing rows, mind you - it only validates that each individual row went through the appropriate business logic. You could potentially include a signature for the whole table, but that starts getting pretty heavy!

Of course, at some point you need a secret - the private part of the signature key. Your code will need access to that... and whoever writes that code could include a back door to email themselves the private key etc. Sooner or later you have to trust someone, I suspect. (You could apply multiple signatures, of course, from different teams - so the teams would have to collude in order to forge anything.)

Jon Skeet
thanks for the well thought out response. +1
Syd
+1 For *applying multiple signatures idea*.
KMan
Given the elapsed time, I have not found no better answer than Jon's. I am happy to accept Jon's. Creating a hash signature of all the entire columns (and not just some peculiar fields) would prevent a DBA from copying another row or copying specific columns. To make this work, each row must have an additional requirement of being time stamped.
Syd
+2  A: 

To be perfectly blunt: you're wasting your time.

DBAs have the equivalent of root access to your database. If not, they're going to be rather ineffective. The same issues arise with system administrators and basically anything you can do is little more than a placebo at best. The only thing you can do about A malicious person with that level of access is not give them the access to begin with.

The best you can do is make it a little harder by creating an audit trail. Log when users log in, log out, what they do, what events the system responds to and so on. The only real value of this is being able to (hopefully) reconstruct what happened if you manually decide to go in and look at it later.

As for changing the result of a soccer match, ask yourself how likely that is to happen. Of course it doesn't actually change the result of the soccer match. It simply change how it was recorded. Anyone who saw it or participated will be aware of the actual result so what value is there in someone changing it on the system?

In companies, error and malice and handled by reconciliation processes. A stockbroker will have a team that runs reports on what's on the system and compare it to bank transactions actually done. Any discrepancies get red flagged. So you could change your balance on the system but it will get backed up.

The other part of this puzzle is that restrictions on DBA activity won't actually solve the problem. Application developers can release arbitrary code. Even if it's reviewed the system can still break down at build engineers or someone with root-level access to the production environment compiling a modified version and running that.

cletus
Even when we are using the soccer match as the simplest example, you would be surprised that it is likely that someone may want the result to be changed if the result can improve one's points in a tipping competition especially when the change is done before the actual points is being allocated. I disagree with your first point that the by the DBA having root access, he can change anything. However, I take your point on the need for audit trail (+1). For a simple system, I do not have to implement audit trail but I will add this consideration when I am designing a more complex system.
Syd
I wonder why you have left meta-stackoverflow? I'm just reading one of your questions there, and upvoted it and put a bounty
Johannes Schaub - litb
@Johannes.. Already 2 days but only two answers. I am sure that there are others who have dealt with this before. It would be so good to get them to share their experience into making a better design. I will wait for 3 more days. If there is no better answer, I will do the marking (current Jon is leading).
Syd