On Fri, Apr 17, 2009 at 09:52:30AM -0400, Bill Moran wrote: > In response to Sam Mason <sam@xxxxxxxxxxxxx>: > > For example; you say that you don't trust the application, yet the user > > must trust the application as they're entering their secret into it. > > How does the user ascertain that the application they're talking to is > > the "real" one and that it hasn't been replaced with a pretend one that > > sends their secret off to an attacker who has access to a real version > > of the program? > > The primary portal into the application right now is a web site. As > a result, this part of it is handled by typical SSL certs and the like. OK, that defers the problem nicely. > As far as the trust factor, you've blurred the lines a bit. My job > is to ensure that the user doesn't know or care about the lines between > application and database, but trusts the system as a whole. However, > I need to clearly define those lines and ensure that each part of > the whole has enough security measures to withstand a flaw in one > of the other parts. Think of the design of postfix, where each > program (smtpd, qmgr, etc) doesn't trust the input of the other > programs and runs in its own sandbox. Sorry; my example of where to place trust was a bad one, lets try some other ones: The Postgres process; do you trust that the database engine is secure? This implies that the frontend program can send the user's secret to the database engine and the decryption will be done "inside" the database. I believe this to be the case, otherwise for the user to query on SSN, to pick an example you were using before, you would need to send *every* encrypted SSN to the client where they would decrypt it with their secret to find the one they wanted. Backups; you mentioned that if someone stole the backups they shouldn't be able to get any more information than if they were using the client interface. If every sensitive field is encrypted then you're protected against some attacks, but you'd be better encrypting the backup. Where is it OK to place the trust here? -- Sam http://samason.me.uk/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
