>You will not be able to search on encrypted fields.
Sure you can. MySQL will also be able to use the index provided you are
using an "=" when searching. But you can't use ">" or "<" on an encrypted
field and still expect it to use an index.
I've found talking to MySQL developers about the need to use encryption on
their data is a lot like talking to a bunch of nudists and advising them it
is "desirable" to wear clothes when you're in town shopping. There are just
some things that need to be hidden. :-)
I use encryption all the time on my Windows databases (not MySQL) because
they make it so effortless with table wide transparent strong encryption. I
can use Blowfish, AES or several others. I can even implement my own if I
Why the need for database encryption?
1) Customers who buy your vertical market application like to get into the
data files and change things. Their resident tech guy who took a 3 hour
course on Access feels compelled to view and edit some of your table data.
He likes to go exploring during lunch to see what data he can find. Since
he's the resident "administrator" he has all the passwords. And when things
go wrong, it's the developer's fault so you better come fix it.
2) Data often walks out of offices with employees. The confidential data on
the backup drive that went missing last week is now on the internet. The
guy who was fired last week is now threatening to release the payroll
salaries unless he's paid $10,000 to return the database files he copied to
his USB thumbdrive. It's impossble to protect a MySQL database if the
person has physical access to it.
3) Did your IT department remember to scrub the drive they replaced last
week? Or did they sell it on eBay with the database still on it?
4) Bill forgot his laptop in the taxi yesterday and it has our sales
database on it. Do you think anyone will have the nerve to sell it to our
competitors? Hmmm. Better update my resume.
5) Hackers are intensifying their attacks on corporate data. Organized
crime is spending considerably effort to hack into corporate data files.
6) Identity Theft. Personal information for hundreds of thousands of people
are lost each month and it seems to be getting worse. The U.S. government
alone is one of the more flagrant violators of personal information. Retail
chains don't have strong enough security and continually lose customers'
data. Take a look at what happened to Winners, Home Sense, TJ Maxx etc..
Or how about the possible 8 million credit card customers whose information
may have been lost? 8 MILLION!
These companies now face class action lawsuits from their customers. Just
to defend these claims is going to be expensive. I can't imagine how much
they are going to have to pay when they lose the case, especially if they
are a repeat offender. The 3rd party developer(s) who wrote their database,
will likely be named in the case too so they can expect to spend a lot of
time away from work.
I really don't like using MySQL to store any type of corporate data. I
automatically assume anything stored on my MySQL database will eventually
find its way on the internet or into the hands of my competitor. MySQL is
far to easy to hack. (And so are a large number of other databases too).
Using MySQL on a webserver is fine, if the data isn't critical. If you
don't want to write it on a postcard and mail it, then don't store it in a
MySQL database, or any other database that doesn't support transparent
encryption. IMHO, MySQL AB doesn't feel encryption is necessary. However
governments are enacting new laws to put the onus on corporations to
protect their data or face heavy penalties. Unless MySQL AB starts
implementing better security, developers could find themselves being
disqualified from getting government contracts.
And for those of you who still don't think encryption is necessary, well,
enjoy the sunshine and don't reveal anything too important. :)
P.S. And where DO you put your wallet when you shop? <g>