First: I have suggested such, in the message where I stated that many hotels don't allow connections on port 3306 (which is MySQL's standard data port). Create a proxy that sits on a webserver, using XML-RPC to accept requests from the client. Perform whatever logic checking you need there, and log every access.
Second: You can manipulate the database, but can you look back and audit the manipulations you make to the database? You stated that you don't think that you have the ability at the MySQL layer to see what the clients are doing, much less what they have done. Third: If you're the security consultant, why should I have to provide free consulting for you to be able to profit from? There's a LOT of books on the topic, and I would recommend that you read them. Basically, at every step, do whatever you have to to mitigate the damage that an attacker can do. Don't allow DELETE access from critical tables to your users, add a boolean column that states whether the record has been deleted, and only after you have ensured that those records are backed up should you purge them (which can be done from a user account which does have DELETE access: 'delete from table where (backedup == true and deleted == true)'. You must model the security threats against your database, and find ways to mitigate them and identify people responsible for attempts to breach security so that their ability to threaten your database can be removed. Without details (and money for my time :P) I can't perform this analysis for you. -Kyle H On Fri, Dec 26, 2008 at 5:47 AM, Edward Diener <el...@tropicsoft.com> wrote: > Kyle Hamilton wrote: >> >> 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. > > Please suggest ways to do so. The server is no different from any other > server database. It accepts a username/password to prevent unauthorized > users from accessing its data. I am perfectly willing to listen to other > server techniques which involve security, or read about such techniques, but > I need to be pointed to such things. Just generally saying what you say is > not going to help me. I am open to specific suggestions if you want to give > them. > >> 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 is not the psychology of the company for which I am working. > >> 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. > > Why do you say "Since you admitted..." etc. ? The server database is > accessible and manipulatable in whatever ways we want to manipulate it. > >> >> If your company hires a security consultant, s/he will state the same >> thing. > > Thanks for your help but right now I am the programmer and "security > consultant", and therefore I must come up with security answers. Nonetheless > I will mention to my employer that he might want to hire another person as a > "security consultant" to deal with server side security issues. > >> >> -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 >> > > ______________________________________________________________________ > 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
