I can understand the need to store encrypted data that needs to be decryptable. It would be a significant improvement over how a popular (and expensive) product like Plesk works, where it stores all email, client, FTP and DB usernames and passwords in plain text as default, hoping that splitting the data across multiple tables will baffle a would-be intruder. It's not hard to beat though. If you are using Plesk on your servers then for the love of God, make sure that access to the PSA database is heavily restricted!
You're probably better off to ask the question in the PHP forum, if it's PHP that you're using server-side. PHP has some very powerful encryption available. Take a look here: http://php.net/manual/en/refs.crypto.php
mcrypt will probably be the one that you need to look at.
I've worked on PCI-DSS compliant systems in the past where we've had to store credit card information, and the way that we did it was to obfuscate the code as heavily as possible so that it was difficult for someone to work out what was happening if the filesystem was compromised. We also used a very large key that was partially stored in the database and partially stored in the filesystem. The reason being that if one is compromised then the attacker only gets half of the key and still has a lot of work to do to calculate the rest. We also put checks in place for the web panel to automatically disable any user account that appeared to be abusing the system (ie looked at too many cards in too short a time for it to be legitimate use).
Also, if you REALLY don't want people to get in, then you need to restrict access to your database as well. Ensure that the root user has a heavy password and disallow any connections from an external IP. Create a user for the website that is unable to create new users or grant/revoke any permissions and only allow it access from the webserver IP. If you're working on the database remotely then create yourself your own user account and again, restrict the IP to your workstation's IP. If this varies regularly (dynamic IP) then you'll need to ensure that you can change it through another account, preferably only accessible from the DB server itself, and SSH in with a secure password and make the change there. If you need to allow external apps access to the data then do it through an API of some kind, and never a direct connection to the database.
I think that ticks most of the boxes. Oh, and if you CAN use a hash instead of encryption, do so!