Transparent encryption with Hibernate

The security people at my were suggesting that we needed to create an encryption service, to securely store passwords so that even rogue DBAs could not get at them. The idea is that no matter how good your access is to the database, you shouldn’t be able to decrypt the passwords unless you have the secret key. In a solution like this, the key is generally stored offline with the application and loaded into memory sometime during startup. The encrypted data never leaves the database.

Here is what I want:

Here, EncryptedEntity is an entity that has some property encrypted. The EncryptedEntity.secretMessage property is just a String variable. All the magic happens in the Hibernate mapping file:

The interesting bits are in EncryptedStringUserType, which implements org.hibernate.usertype.UserType. Here is the code for saving the String property.

Reading and decrypting is the same, mutatis mutandis. The master key is of course set by the tests. One example may be as a global variable:

Get the full EncryptedStringUserType to see the not so gory details (notice: This is implemented with “Password Based Encryption”, but it should be simple to replace it with any Java Encryption algorithm you’d like.

Copyright © 2006 Johannes Brodwall. All Rights Reserved.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Java, Software Development. Bookmark the permalink.
  • Erlend

    Why do you want to store the passwords encrypted? Do you have any special requirements that requires you to be able to retrieve the password in clear-text? If not, hashing the password with a secure hash-algorithm is the only way to go.

  • http://brodwall.com/johannes/ Johannes Brodwall

    Good question, Erlend. But the answer is obvious: The passwords are passwords that we use to log in to other systems. (Actually, the primary use case is private cryptographic keys)

    If these were passwords of users that we wanted to authenticate, I agree that hashing the passwords would be the correct solution.

  • Erlend

    Why do you want to store the passwords encrypted? Do you have any special requirements that requires you to be able to retrieve the password in clear-text? If not, hashing the password with a secure hash-algorithm is the only way to go.

  • http://brodwall.com/johannes/ Johannes Brodwall

    Good question, Erlend. But the answer is obvious: The passwords are passwords that we use to log in to other systems. (Actually, the primary use case is private cryptographic keys)

    If these were passwords of users that we wanted to authenticate, I agree that hashing the passwords would be the correct solution.

  • Daniel Fernández Garrido

    Hello,

    I found this post, four months old, doing some research on already existing things “out there” for transparent encryption.

    I am the the founder of the Jasypt (Java Simplified Encryption) project, which among other things, provides a hibernate integration module for doing precisely this, transparent encryption of stored data.

    You can have a look at it at http://www.jasypt.org

    Regards,
    Daniel.

  • Daniel Fernández Garrido

    Hello,

    I found this post, four months old, doing some research on already existing things “out there” for transparent encryption.

    I am the the founder of the Jasypt (Java Simplified Encryption) project, which among other things, provides a hibernate integration module for doing precisely this, transparent encryption of stored data.

    You can have a look at it at http://www.jasypt.org

    Regards,
    Daniel.

  • http://brodwall.com/johannes/ Johannes Brodwall

    Hi, Daniel

    These tools look real cool (and simple to use). Have you considered implementing signing data in the same way?

  • http://brodwall.com/johannes/ Johannes Brodwall

    Hi, Daniel

    These tools look real cool (and simple to use). Have you considered implementing signing data in the same way?

  • Daniel Fernández Garrido

    Hello Johannes,

    If you mean adding asymmetric encryption techniques to jasypt, yes, that is in my to-do (maybe in a couple of versions). For the moment only message digests and password-based encryption are supported.

    And by the way, version 1.2 of jasypt (to be released early in April) will add support for transparent hibernate encryption of: BigIntegers, BigDecimals, Bytes, Shorts, Integers, Longs, Floats, Doubles, Dates, Calendars, Booleans and byte[]'s (blobs). This way it will cover the full range of data types most frequently used for attributes of persistent entities.

    Thanks for your interest.

    Regards,
    Daniel.

  • Daniel Fernández Garrido

    Hello Johannes,

    If you mean adding asymmetric encryption techniques to jasypt, yes, that is in my to-do (maybe in a couple of versions). For the moment only message digests and password-based encryption are supported.

    And by the way, version 1.2 of jasypt (to be released early in April) will add support for transparent hibernate encryption of: BigIntegers, BigDecimals, Bytes, Shorts, Integers, Longs, Floats, Doubles, Dates, Calendars, Booleans and byte[]’s (blobs). This way it will cover the full range of data types most frequently used for attributes of persistent entities.

    Thanks for your interest.

    Regards,
    Daniel.

  • http://brodwall.com/johannes/ Johannes Brodwall

    Hi, Daniel

    Signatures requires a little more than asymmetric encryption, most notably, one has to consider where to store the actual signature. There's also a danger of replay-attacks if you don't include the primary key in the hash, so there are a few issues to consider to make it transparent. Nothing very impossible, though.

    With regard to the different data types, have you analyzed whether encryption like this is appropriate for very short data types? It seems to me that the shorter the data type, the easier it will be to somehow brute force it. But I might have misunderstood the fundamentals of encryption here.

    ~Johannes

  • http://brodwall.com/johannes/ Johannes Brodwall

    Hi, Daniel

    Signatures requires a little more than asymmetric encryption, most notably, one has to consider where to store the actual signature. There’s also a danger of replay-attacks if you don’t include the primary key in the hash, so there are a few issues to consider to make it transparent. Nothing very impossible, though.

    With regard to the different data types, have you analyzed whether encryption like this is appropriate for very short data types? It seems to me that the shorter the data type, the easier it will be to somehow brute force it. But I might have misunderstood the fundamentals of encryption here.

    ~Johannes

  • Daniel Fernández Garrido

    Hello Johannes,

    About short data types – yes, they could be easier to brute force, but only if we didn't generate the encryption key with the enough strength. In PBE, if we follow the RSA standards (and jasypt does), for generating the encryption key, the password is added a (preferably random) salt, and then it is applied a hash function a number of times (iteration count).

    The addition of a random salt, and the application of a hash function many times (RSA recommends at least 1,000) adds an important strength to the resulting encryption key (it is the same process as described in “Encrypting Passwords” in the jasypt website http://www.jasypt.org/encrypting-passwords.html), and, among other desirable effects, allow the domain of the result of the encryption of a small domain like a Byte object be much more diverse and big than the original domain.

    This is, with a Byte object we will have 256 possible values; but once encrypted, we will have much more. (And also we will need more space to store it, of course). Brute force won't be that easy, here.

    Regards,
    Daniel.

  • Daniel Fernández Garrido

    Hello Johannes,

    About short data types – yes, they could be easier to brute force, but only if we didn’t generate the encryption key with the enough strength. In PBE, if we follow the RSA standards (and jasypt does), for generating the encryption key, the password is added a (preferably random) salt, and then it is applied a hash function a number of times (iteration count).

    The addition of a random salt, and the application of a hash function many times (RSA recommends at least 1,000) adds an important strength to the resulting encryption key (it is the same process as described in “Encrypting Passwords” in the jasypt website http://www.jasypt.org/encrypting-passwords.html), and, among other desirable effects, allow the domain of the result of the encryption of a small domain like a Byte object be much more diverse and big than the original domain.

    This is, with a Byte object we will have 256 possible values; but once encrypted, we will have much more. (And also we will need more space to store it, of course). Brute force won’t be that easy, here.

    Regards,
    Daniel.

  • http://brodwall.com/johannes/ Johannes Brodwall

    Hi, Daniel

    Thanks for a good introduction on how to encrypt small amounts of data. Your comment helped correct some of my confusion on the subject.

  • http://brodwall.com/johannes/ Johannes Brodwall

    Hi, Daniel

    Thanks for a good introduction on how to encrypt small amounts of data. Your comment helped correct some of my confusion on the subject.