I am focusing on a Grails 1..4 project that needs to be launched in under 2 days, and also the customer just emerged having a requirement that data within the database ought to be encoded.

Since file encryption of each and every database access within the application itself might take considerable time and will also be error prone, the answer I seek is a few type of file encryption transparent towards the application.

It is possible to method to setup Hibernate to secure all data in most tables (except maybie the id and version posts) or must i seek a MySQL solution (we are using MySQL 5.) ?

EDIT: Thanks for all your posts for alternative solutions, when the customer changes mind it is always good. For now, the necessity is "No plain text within the Database".

Second factor Let me explain is the fact that I am using Grails, for individuals not fammiliar by using it, It is a convention over configuration, so even small changes towards the application that aren't by convention ought to be prevented.

Should you finish carrying it out within the application, you should use Hibernate custom types also it wouldn't include that many changes for your code.

Here's an encoded string custom type that I have used:

import org.hibernate.usertype.UserType
import org.apache.log4j.Logger

import java.sql.PreparedStatement
import java.sql.ResultSet
import java.sql.SQLException
import java.sql.Types

class EncryptedString implements UserType {

  // prefix category name with 'org.hibernate.type' to make logging of all types easier
  private final Logger _log = Logger.getLogger('org.hibernate.type.com.yourcompany.EncryptedString')

  Object nullSafeGet(ResultSet rs, String[] names, Object owner) throws SQLException {
    String value = rs.getString(names[0])

    if (!value) {
      _log.trace "returning null as column: $names[0]"
      return null

    _log.trace "returning '$value' as column: $names[0]"
    return CryptoUtils.decrypt(value)

  void nullSafeSet(PreparedStatement st, Object value, int index) throws SQLException {
    if (value) {
      String encrypted = CryptoUtils.encrypt(value.toString())
      _log.trace "binding '$encrypted' to parameter: $index"
      st.setString index, encrypted
    else {
      _log.trace "binding null to parameter: $index"
      st.setNull(index, Types.VARCHAR)

  Class<String> returnedClass() { String }

  int[] sqlTypes() { [Types.VARCHAR] as int[] }

  Object assemble(Serializable cached, Object owner) { cached.toString() }

  Object deepCopy(Object value) { value.toString() }

  Serializable disassemble(Object value) { value.toString() }

  boolean equals(Object x, Object y) { x == y }

  int hashCode(Object x) { x.hashCode() }

  boolean isMutable() { true }

  Object replace(Object original, Object target, Object owner) { original }

and according to this it ought to be easy to create similar classes for int, lengthy, etc. To make use of it, add the kind towards the mapping closure:

class MyDomainClass {

  String name
  String otherField

  static mapping = {
    name type: EncryptedString
    otherField type: EncryptedString

I overlooked the CryptoUtils.secure() and CryptoUtils.decrypt() techniques since that isn't Grails-specific. We are using AES, e.g. "Cipher cipher = Cipher.getInstance('AES/CBC/PKCS5Padding')". Anything you finish up using, make certain it is a 2-way crypto, i.e. avoid using SHA-256.

When the customer is anxious someone complain about physically leaving using the hard disk then utilizing a full disk solution like Truecrypt should work. If there concerned about traffic being sniffed then have a look at this area of the mysql documentation on ssl over JDBC. Remember if a person compromises your server all bets are off.

the client could easily do that without altering a factor inside your application.

first, secure the communications between your server by activating SSL within the mysql layer, or make use of an SSH tunnel.

second, keep mysql database with an encoded volume.

any attack that may expose the filesystem from the mysql database or even the qualifications required to log to the mysql server isn't mitigated by encrypting the information since that same attack may be used to retrieve the file encryption key in the application itself.