On Wed, 08 Jan 2003 00:47:37 CST, Frank Knobbe said: > Yeah, but isn't that the whole point? Move the 'problem' (of accessing > the raw/unencrypted data) to a more trusted zone. If you can encrypt the > data in a non-reversible fashion (at least as far as this machine is > concerned), you don't even need to worry about the passphrase (as can be > found in the script anyway). You only have to worry about securely > destroying the plain text after encryption. I believe the 'problem' of > safeguarding the data from unauthorized access (presuming plain text is > wiped) is solved. Only if you consider "problem merely moved to a different host" as "solved". Remember - the threat model probably does *not* worry about J Random Scripkid as much as it does about J Disgruntled Insider. And I think it's a given that if an insider knows the fun data is on www.bigcorp.com, they can figure out that it's being copied to backroom.bigcorp.com. Also, remember that often the backroom operations are more complicated than the front end (think all the data mining, etc...) and as a result the "more trusted" zone will probably have almost as many people with legitimate access as the front-end box. Of course, if they're that worried, the webserver should probably be using SSL to the user - and who wants to place bets that the SSL key doesn't have a passphrase on it either? Proper security design is about threat analysis and then tradeoff analysis. I think the original poster will have to make up a list of "We can do X, which will make it Y harder to crack, but add Z cost/overhead/pain-in-bodypart to the product" and upper management will have to made a (hopefully) educated choice on what set of X they want to deploy. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 10:01:42 PST