Re: Database Encryption (now required by law in Italy)
От | Matt Davies |
---|---|
Тема | Re: Database Encryption (now required by law in Italy) |
Дата | |
Msg-id | 1078497790.404891feec25d@www.mattdavies.net обсуждение исходный текст |
Ответ на | Re: Database Encryption (now required by law in Italy) (Mitch Pirtle <mitchy@spacemonkeylabs.com>) |
Ответы |
Re: Database Encryption (now required by law in Italy)
Re: Database Encryption (now required by law in Italy) |
Список | pgsql-admin |
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 <mitchy@spacemonkeylabs.com>: > 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 majordomo@postgresql.org >
В списке pgsql-admin по дате отправления: