0

I would like to have a way to validate / authenticate a field in a DB.

I have an SQL database where one of the tables has some payment data (most importantly - a USERID, a DATE and a SUM). I would like to make sure the data hasn't been altered by a hacker or any other way - so in fact the triplet of (userid, data, sum) hasn't been altered by an unauthorized intruder.

My idea was to create a hash field - with those 3 fields + a secret token + a random nonce for each row. Then I'll be able to validate the signature with my secret token.

Does this even make sense? Is there a better way to do this?

Thanks

Roman
  • 4,443
  • 14
  • 56
  • 81
  • 1
    why would you want this? when would you validate its checksum? How are you attributing the secret token and the random nonce back to a specific row to rehash its values and then check for validity? This seems unnecessary to me - assuming your database is not accessed directly by administrators, your CRUD endpoints do not allow for the updating of these fields, and you have protected yourself against sql injection. – Kritner Jan 22 '15 at 20:30
  • 1
    I generally agree with @Kritner. Assuming good answers to their questions, then: how secret is your token? You need it to build the hash... where is it kept, how is it accessed, and how is the hacker denied this knowledge? Recommendation: read up on how this and similar security problems are addressed in Real World situations (Banks, Finance companies, etc.) – Philip Kelley Jan 22 '15 at 20:44
  • Thanks guys. Will try to read more on this subject. – Roman Jan 22 '15 at 21:35
  • Another way of looking at it. I would consider adding an audit log, which would contain history of all modifications to the data. In this case you would be able to trace who and when modified the row. Of course, audit logs also can be hacked, it is just another helper layer. – Vladimir Baranov Jan 22 '15 at 23:20

0 Answers0