Re: Hiding data in postgresql - Mailing list pgsql-general

On 5/25/2010 2:58 AM, Hector Beyers wrote:

No, I have not considered encrypting or decrypting data. The reason for this is that I am trying to secure a database by thinking like a malicious user / criminal. I want to hide (for example) fraudulent data on a database where it is not easily seen by others and then build a tool to detect this hidden data. 

On your questions:

*) What data is to remain secret?
*) Who is allowed to see the secret data?
*) When do they see it?
*) What sacrifices are you willing to make to keep the data secret?
*) Where are you going to store the key?

the answers:

• fraudulent data / or data that needs to be hidden.
• only the malicious user - and hopefully later a detection mechanism that I aim to build.
• I don't really have a preference on when they can see the data, but maybe when you export a dump. 
• The main purpose of hiding the data is that the normal users of the database will not easily find the hidden data. If this criteria is met, then any other sacrifices can be made. 
• Still need to figure that one out. 

Any good brainstorming ideas will help!

Missed this bit prior to first responds. 

I think some of the assumptions here are flawed.

If hacker actually got into a database why would they do this???  what is being accomplished???  why would anyone want to do this???

Again it would make allot more sense if a hacker stored data in plain site.  Create  tables that look like real tables following the same naming schema or use already existing tables like logs, Modify the tables adding columns to store data.  Then create/update records encrypting the contents, this would protect the contents from ever being read by anyone except by the creator. 

Think this line through  how long would a Hacker go unnoticed if they used the already existing tables adding in columns or take over stale records like old customers that are no longer active.  Then use the text fields to store data.  The hacker could create normal user account to access those records throwing up no red flags.  How many people review table structures or update to already existing records. 

The current crop of hackers are not hexeditor high-school wannabe's. Hackers want to go unnoticed for as long as they can so that means doing nothing out of ordinary that throws up red flags. 

Just read up on the investigations on stolen credit cards.  Or fake ATMS that's been installed at malls.  The hackers/thieves figured out how to go unnoticed for long periods of time by appearing normal. 

Second assumption is the hacker actual got a admin/root  level access  to be able to do these kind of things.  This means security upfront was lacks which point there are far bigger problems than hidden data.  

Far better way to secure is not trying think what they can do once they get access, but stop them getting in to start with.    If anyone gets this high level of access protecting from or figuring out if they have hidden data is immaterial to the problems someone has.








All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by our proprietary quotation system. Quotations received via any other form of communication will not be honored.

CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other information proprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it addresses. If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified that any unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this e-mail immediately.
Thank you.