And how does one account for key information? If one encrypts any information
deemed worthy to be a key then you have to decrypt the entire database to find
particular information.
Of course, you could keep keys unencrypted for use, but then again, why encrypt
it at all?
Quoting Mitch Pirtle <[EMAIL PROTECTED]>:
> Dave Ewart wrote:
>
> > If you find any 'automated' front-end to do this at the database-level,
> > rather than something like loopback at the filesystem level or at the
> > field level for specific fields, I think there would be a lot of
> > interest.
>
> But that is the problem, isn't it? Any 'automated'
> encryption/decryption will be just as useful to the would-be perpetrator
> of data theft. This is like having an automatic alarm system on your
> car that works for anyone that walks up to it.
>
> The same logic applies to encrypting the data in the database -
> somewhere on your server the application has to know how to decrypt it,
> and that means anyone that gains access to your server will have that
> ability also...
>
> I understand (and demand) requiring SSL connections for database
> clients, and MD5 hashing of passwords before storing in the database,
> but implementing two-way encryption of database data just doesn't make
> sense to me.
>
> -- Mitch
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
