Unix Technical Forum

about high security field

This is a discussion on about high security field within the DB2 forums, part of the Database Server Software category; --> Hi All I am designing DB2 database. I have some entities each has nearly 40-60 attributes. Each of these ...


Go Back   Unix Technical Forum > Database Server Software > DB2

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 02-27-2008, 07:27 AM
Suresh
 
Posts: n/a
Default about high security field

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.

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 02-27-2008, 07:29 AM
Jonathan Leffler
 
Posts: n/a
Default Re: about high security field

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: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 02-27-2008, 07:29 AM
Suresh
 
Posts: n/a
Default Re: about high security field

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.

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 02-27-2008, 07:29 AM
Brian Tkatch
 
Posts: n/a
Default Re: about high security field

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.

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #5 (permalink)  
Old 02-27-2008, 07:29 AM
Suresh
 
Posts: n/a
Default Re: about high security field

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.

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #6 (permalink)  
Old 02-27-2008, 07:29 AM
Brian Tkatch
 
Posts: n/a
Default Re: about high security field

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.

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 10:03 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com