Hi MySQL'ers -- I run multiple HIPAA compliant databases and a lot of very secure patient information in my MySQL databases.
However, I am a bit of a security phreak and want to go a step further and encode the data INSIDE the database so that, in the very unlikely event that someone can bum-rush my security guards, break past the bullet-proof door walls, and rip out my hard drives through the locked rack cabinet, I want to ensure my data is safe. Also, I want to make it so that you cannot even LOOK at the data unless you know the correct encryption keys. I currently employ AES encryption for keeping passwords and such, and have been very successful in doing so. However, I have run into a snag and I am hoping that you all can suggest ways to rectify this or provide better ideas than I currently employ. Quick Rundown: MySQL 5.0.38 running on Debian Linux, Kernel 2.6, fully up-to-date. Server Side Language - ASP (yes, I know, don't say anything....) Web Server - IIS 6.0, Windows Server 2003 SP2. ODBC - MyODBC 3.15.17 5 different firewalls (3x Linux (technically 1 firewall, 3 chains), 1 Windows, 1 hardware router firewall). 1024-bit SSL encryption from client to Web app, 256-bit SSL from Web app to MySQL (and the server will kick you if you are not using SSL). Here are the questions at hand: 1) When using any encryption method, I continuously get a "Error Nr 2014: Commands out of sync." I have checked the manual, but it does not provide any helpful information, as I can be connecting only through the CLI on my Linux box and it gives me the same error. MySQL Query Browser also supplies said error. Question: What exactly are the correct command sequences so as I can rectify this error, and why do I get it from 3 different clients, even when I am the only one connected? 2) When using any encryption method, I can successfully ENCODE, DECODE, AES_ENCRYPT, and AES_DECRYPT all of the necessary data, however, the Query Browser (and hence, my app) cannot display the data as it seems as though the column length is NULL, even though you can expand the column and see the data. The CLI reports the data correctly. The fields in question are LONGTEXT. Is this a case where encoding or encryption is not worth the CPU clocks, or is the field just too long to encode? Should I consider moving these to VARCHAR() instead of LONGTEXT? 3) We do research-based data mining on these records, and of course, encryption will hinder this process. Would setting up temp tables with the unencrypted data be the best course of action for doing the research that is necessary? Thank you for your time and I look forward to discussing these issues with you. J.R.
