NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/database/ingres/2234

Text File | 1993-01-12 | 4.6 KB | 91 lines

Newsgroups: comp.databases.ingres
Path: sparky!uunet!caen!sol.ctr.columbia.edu!news.columbia.edu!usenet
From: [e-mail] (Alan Crosswell)
Subject: Re: Encryption
Message-ID: <[e-mail]>
Sender: [e-mail] (The Network News)
Nntp-Posting-Host: curta.cc.columbia.edu
Organization: Columbia University
References: <[e-mail]>
Date: Tue, 12 Jan 1993 22:14:08 GMT
Lines: 78

In article <[e-mail]> [e-mail] (Chris
Amidei) writes:
> [e-mail] (Chris Renck) writes:
> : We are developing a application which is going to contain salary
information,
> : and I was wondering if anyone has any suggestions on how the salary field
> :  can be encrypted or secure so only authorized people can see it.  Our
Human
> : Resources Dept does not even wants us (the Ingres developers) to be able to
> : see what data is in this field.
> :
>
> How about taking a queue from Unix and the Shadow Password concept.  User
> information that is viewable is stored in one file that everyone can read
> while other information that should not be viewable by everyone (ie.
passwords)
> is stored in another file only readable by those who need the information.
>
> With Ingres, the same can be done.  One table contains globably viewable
> information, the other would contain salary information that is viewable only
> by those who should.  Create database procedures to add, remove and modify
> employees, thus helping to ensure integrity.
>
> For Applications, make the salary display field 'invisible' to those who
should
> not see the information.
>
> Or, you could create a view through which most users access data through.
> This view would NOT contain the salary column.
>
> --
> The last thing the bungee jumper heard: Gee, I thought I was next?
> ------------------------------------------------------------------------
> Chris Amidei        | E-mail: [e-mail]
> Instructor            |  Phone: [phone] - my desk
> Ingres, an Ask Company    |       : [phone] - main line

The point is that the data could still be read by anyone with sufficient
operating system privileges to read any file or someone with sufficient
Ingres privileges to read the given table (such as the person who is the
DBA).  Unix passwords are different in that they are one-way encrypted.  Even
if you steal the password file, you can't reverse the encryption to get
someone's password.  The best you can hope to do is brute-force attack the
passwords with a password guesser -- which is pretty easy given how easy
to guess most passwords are.

Unfortunately, for this application, I assume they wan't to be able to
see what the value is and not just see if it matches what you think it should
be so one-way encryption is out:-)

To do encryption the way it is being aksed for is non-trivial and is really
unrelated to ingres per-se.  You need to come up with some encryption algorithm
and a method of securely distribution the keys for it.  For example, if you use
a symmetric algorithm like DES, then you need a 56-bit key which is used
to both encrypt and decrypt the value.  Then, the finance people should
write this key down on a post-it-note next to their screen, since they
can't store the key on the host since they don't trust the DBA, developers, or
sysadmins to maintain confidentiality.  Of course, if the encryption/decryption
and data entry/display is done on the host in the Ingres application, then
you already have the data available at some point in time at least in
memory and probably on the system swap disk too, not to mention it is flowing
back and forth across the network in the clear and that pesky developer
could have dropped off a backdoor or two while he was at it....

So, it is really an issue of risk analysis.  What is the cost of going hog-wild
with this vs. the cost of some trusted person discovering and disclosing it?
Could the client live with a scenario during which the developers are supplied
with bogus test data until the system goes into production at which point real
data is load in and the developers have their SQL permissions removed?  Can
the DBA and system administrators be trusted to maintain confidential data?
Are sufficient controls in place such as audit, staff education about the
importance of preserving confidentiality, etc.

I think what is needed is better educating the finance people about the limits
of the technology and assuring them that a small subset of staff will always
have to be trusted.  After all, what's to prevent a clerk in the finance
department from disclosing the information?  Certainly not technology.
/a