On Thu, Jun 16, 2011 at 3:35 AM, Manuel Gysin <manuel.gysin@xxxxxxxxxxxxxxxxx> wrote: > I can trust the dba. But while someone gain access, he can control everything and could easily extend his rights to dba. > An other way with client side encryption/decryption should be possible with deployed certificates and keys, but so only the user has access to the data. With all due respect, I don't think you can trust the dba. People are always the weakest link in any security chain. Don't think of the specific person, but more the role involved and what data that person should be allowed to see. Imagine explaining to your customers that certain of your personnel will have access to credit card numbers or other highly sensitive information. Imagine explaining it to an auditor. OTOH, maybe your security expectations are a little too high -- it's always a tradeoff between security and usability (this is why we don't encrypt addresses). If you are talking about the specific case of credit card number processing, there are strict protocols that have to be followed in order to be able to do that. You must submit to an audit in order to be able to do that (google pci compliance). Password hashing is another thing -- randomly chosen defenses (like repeat hashing or combining algorithms) are, IMNSHO, useless. Better to use salt and, if necessary, do not do the hashing or store the salt on the server. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
