Re: Hiding data in postgresql

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.