about high security field

[Suresh]

Hi All

I am designing DB2 database. I have some entities each has nearly 40-60
attributes. Each of these entity (table) have password, some other
information as high security attribute. So should i create new entity
which hold password data for all entity or should I place password data
in respective entity.In each case i will encrypt password.
in both cases what will be effect with respect to performance and
security.
Each entity (table) have more than 10 million records.

[Jonathan Leffler]

Suresh wrote:

I am designing DB2 database. I have some entities each has nearly 40-60
attributes. Each of these entity (table) have password, some other
information as high security attribute. So should i create new entity
which hold password data for all entity or should I place password data
in respective entity.In each case i will encrypt password.
in both cases what will be effect with respect to performance and
security.
Each entity (table) have more than 10 million records.

Your question/scenario is far from clear to me.

It appears that you have a table with, for sake of argument, 50 assorted
columns for which there is no particular secrecy requirement. You also
want to store a password value that is somehow associated with the other
columns in a record, plus some other sensitive data (the 'high security
attribute' in a single column. You have plans to encrypt the password,
but no specified plan to encrypt or otherwise conceal the sensitive
data. It is not clear whether the same password will be used for each
row or whether each row will have its own (potentially different) password.

Without some explanation of how you plan to control access to the
sensitive data, it is hard to resist the temptation to say "it doesn't
matter how you store the password since it won't be needed to access the
sensitive data". However, you most probably have some ideas that you
simply didn't explain.

Just remember that even using the same password, you won't be able to
encrypt the same input data twice and get the same encrypted string -
the encryption functions are the antithesis of an 'invariant' function.
An invariant function always returns the same result for the same
input data; encryption functions, like random number generators, return
a different result each time they're called. It isn't until you've done
a very large number of iterations (2^28 or so for DES encryption; 2^56
or so for Triple-DES) that you run into the Birthday Paradox and might
expect a repeat somewhere in that vast set of values (1/4 billion or so
for DES, lots more for Triple-DES). If you need to produce (and store)
the same result each time and yet conceal the input, you probably need a
cryptographic hash (such as MD5 or SHA-1 or SHA-256; beware MD5 and
SHA-1 have both been somewhat compromised - but that may not be enough
of a problem to worry you) rather than encryption.

--
Jonathan Leffler #include <disclaimer.h>
Email: jl******@earthlink.net, jl******@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

[Suresh]

Here I am explaining my problem once again.....
Actually When I had done database normalisation of web database I found
some entities having more than 50-60 attributes. Each row of entity
represent particular master record. Suppose my entity is customer. if
particular customer want to access his information through web we allot
them user name and password. this entity have some high security fields
like password (which is used to access information through web and each
row has different password) , credit card number etc.We are storing
this password information, high security fields in encrypted form. So
should we store such fields in same table or design another table and
give access rights to very small no. of people (like DBA or system
admionistrator) so that data will not be accessed by any mean. But in
this scenario (design two tables and one-one relationship) what will be
effect with respect to performance.

[Brian Tkatch]

IIRC, the standard approach is not to GRANT SELECT privileges on the
TABLE containing the sensitive data. Instead, CREATE a VIEW to display
the non-sensitive data, and grant access to that.

B.

[Suresh]

Can I create one table with all attribute or two tables with division
of attribute (secured and non secured) . then create view on both table
to access them and add previleges to view.

[Brian Tkatch]

Yes and yes.

Just remember, the rights are given to the entire VIEW or the TABLE.

You can post a small example here (say 5 columns instead of 50) for us
to look at. We may all learn something from an example.

B.