Mr Diener: This is, incidentally, why I call it "security theater" -- you're not gaining anything from the actions that you're going through, except "warm and fuzzies" of the people you're entertaining with it (in this case, your boss).
You need to fix your server architecture, which is likely going to involve a lot of work -- work that you're not doing while you're searching for ways to hide authentication credentials which are subject to attack. Yes, it might prevent the casual user from doing it, but the casual user is also unlikely to know what to do with the credentials that he sees anyway. The advanced user will be able to find the credentials, and is more likely going to know how to write SQL to abuse the credentials than the casual user. The practical upshot of this is that you're protecting your infrastructure from people who wouldn't know how to attack it. This is more likely than not going to lead to your company feeling warm and fuzzy, that the system is safe from attack -- which is (ironically) going to lead to more security vulnerabilities that your company is not going to be on the lookout for. This could lead to catastrophic data loss and downtime while you try to figure out how the data in the tables managed to disappear out from under you -- and if the data is of sufficiently high value, it will more likely lead to the data being sucked down by attackers using the credentials. Since you have admitted that you don't have visibility with MySQL directly as to the queries it's receiving and processing, your company is a sitting duck against these types of attacks. If your company hires a security consultant, s/he will state the same thing. -Kyle H On Thu, Dec 25, 2008 at 6:49 PM, Victor Duchovni <victor.ducho...@morganstanley.com> wrote: > On Wed, Dec 24, 2008 at 10:06:59PM -0500, Edward Diener wrote: > >> >It sounds like you are trying to implement DRM with an application that is >> >running on untrusted hardware controlled by a potentially hostile user. >> >You want to ensure that only your code has access to your server, and not >> >modified or user developed code. This is a "whitebox" DRM problem. >> >> Are you saying that any application sold on the market which needs to >> ensure secure access to data on a server outside the client machine on >> which the application runs is a "whitebox" DRM problem ? > > No, I am saying that applications where you don't trust the user are > DRM problems. If you trust the user (not abuse, modify or replace) > your application, then you don't need DRM, just authenticate trusted > users by giving each user appropriate credentials (possibly a per-user > private key, delivered separately from the application, via a secure > enrollment process). > > -- > Viktor. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
