none
Checking data integrity RRS feed

  • Question

  • Hey folks,

     

    I am trying to figure out a reasonably effective scheme to ensure that once data has been entered, it does not get tampered with. This will likely be on a standalone local-store set of data. I was wondering if anyone has any good suggestions (using stuff like hash codes, encryption, etc) for a system where I can encode/whatever a data row(with an encoded timestamp) to validate against later, to ensure that the data is not changed?

     

    It doesnt have to be bulletproof, just something so that if someone can go in and manually edit data that it would invalidate the row.

     

     I was thining of taking row contents plus a user element (hash of password, username, or something) and putting that hash together when creating a row, that way both the row data and the user currently doing the operation are hashed together to ensure validity.

    Monday, July 2, 2007 4:07 PM

Answers

  • Or you could just add a timestamp field to the row (in SQL Server).

    Any time the row is changed the timestamp field will change.

    Also, you cannot directly set a value to the timestamp field, so users cannot tamper with it.

     

    You could save off the timestamp values (they are convertable to bytes) into another table to use as your "check" table.

     

    This would be much simpler than trying to hash the whole record and would be enforced by the SQL engine.

    Tuesday, July 3, 2007 12:49 AM

All replies

  • That seems like a reasonable scheme, as long as you're not distributing the code that generates the hashes.

    It's got a lot of possible points of failure.  You have to make sure that the hash input for a given row is invariant:  don't do SELECT *, for instance, or include anything (like the user's name) from a joined table.  Make sure nothing in your program messes around with character encoding.

    And you should probably create a private key and include it in the hash input, so that some weisenheimer with time on his hands can't reverse-engineer your hashes.
    Monday, July 2, 2007 8:25 PM
  • Or you could just add a timestamp field to the row (in SQL Server).

    Any time the row is changed the timestamp field will change.

    Also, you cannot directly set a value to the timestamp field, so users cannot tamper with it.

     

    You could save off the timestamp values (they are convertable to bytes) into another table to use as your "check" table.

     

    This would be much simpler than trying to hash the whole record and would be enforced by the SQL engine.

    Tuesday, July 3, 2007 12:49 AM