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 ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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. |
| |||
| 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/ |
| |||
| 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. |