> I have some doubts on how to secure a MySQL database (MyISAM & InnoDb)
> against people who have physical access to the machine. Here are a few
> scenarios.
>
> 1) Let's say I want to use MySQL with my vertical market software but I
> don't want the customer to have access to my data outside of my
> application. I also don't want him to have access to my schema or be able
> to unload the data from the database. If the database is running on the
> customer's machine, he has root access and therefore can get the passwords
> and do anything he wants. My competitor could easily buy the software under
> an assumed name or get a copy from a mutual customer, and then be able to
> reverse engineer my database.
Host the data on a network and make your customers access your machine.
Encryption might be another option, but it would take careful planning
to make sure your application could get the real data while keeping it
away from the customer.
> 2) The database is installed at an ISP and contains valuable data. Someone
> at the ISP could make some easy money if he could unload the data or the
> schema and sell it to my competitor. Heck, my competitor could even open an
> account with the ISP to add some pressure or incentive to the night staff
> to make a few bucks on the side. If the database was on a virtual server,
> he could probably hack into the database without any help from the night
> staff. The problem is I would never know this has happened.
So maintain your own servers.
Again, encryption could help, with careful planning.
> 3) Someone breaks into my office and makes off with my database server. If
> the server is running Win2k, it is pretty easy to circumvent the
> administrator passwords in just a few minutes whether it is encrypted by
> the OS or not.
Well, don't use MSW2k. Or, if you have to use it, use real encryption.
(MSWindows is not Win, by the way. Why help Microsoft "water-up" another
false trademark?)
> I could encrypt certain table fields, but this will make writing the front
> end a pain because all SQL statements will now need to be changed any time
> a new column is encrypted.
No, that's not the way to design the thing. Encryption must be decoupled
from both the database and the application, or you just end up with
obfuscation.
> I also don't know how encrypting index fields
> and large memo's are going to affect performance.
Properly decoupled, the only impact should be the encryption time, and
possibly some tuning issues with MySQL's index generation functions.
Ergo, your application passes queries to the encryption layer, and the
encryption layer munges the vital data and passes it with the query to
MySQL. MySQL does its thing, then gives the (encrypted) results to the
encryption layer, which un-munges the vital data and gives it back to
you.
I could see playing games with fake character set libraries (with MD-5
or something instead of static conversion tables) or with some other
aspect of MySQL's C API, to functionally bury the encryption layer
"inside" MySQL, but you would have to be very careful, or you would just
end up with a little bit more difficult version of the
protect-your-passwords problem.
Trying to provide parsing functions for the encrypted fields (in other
words, for regular expression searches) would be likely to leave the
barn door open for crackers, of course. Any special parsing on the
encrypted fields should be done on the application side, and that might
slow things down (An encrypted index of the un-encrypted data is just
another clue for the crackers, unless you use a separate method (or
separate key, for the stronger methods) for the index.
Of course, even if you implement the encryption as a layer between the
connection driver and mysql, you would still have to be careful to avoid
just building another password puzzler.
> Is there a transparent solution that will solve these problems? TIA
Good question. Let's see what the nearest search engine has to say about
it.
http://www.google.com/search?hl=en&ie=ISO-8859-1&q=encryption+mysql
You might have to dig in a couple of pages, or maybe try a different set
of search keys.
(That's probably not much help, ...)
--
Joel Rees, programmer, Kansai Systems Group
Altech Corporation (Alpsgiken), Osaka, Japan
http://www.alpsgiken.co.jp
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
