Hi, The easiest way to do it is to use Transparent Data Encryption in the RDBMS:
https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-tde For simple use cases, you can just use the @ColumnTransformer as explained in this article: https://vladmihalcea.com/2017/02/24/how-to-encrypt-and-decrypt-data-with-hibernate/ There used to be the Jasypt project which provided encryption for Hibernate, but it does not look like it's very active: http://www.jasypt.org/ Vlad On Fri, Jun 23, 2017 at 8:25 PM, Sebastian Bicchi < sebastian.bic...@sec-research.com> wrote: > Dear all, > > this is my first Thread/Request on this mailing list and maybe I'm > completely wrong here. If so - please excuse that and ignore this message. > > Now back to topic: My small "start-up" was confronted with the problem of > storing sensitive data in the database via hibernate. The data I cared most > about were credentials to APIs, tokens, private keys for signing, etc., in > other words: Data that our application needed in plaintext but also might > help an attacker in case of a breach of the database. Also data that you > not necessarily would reveal to an DBA, especially if you make use of > managed databases (how much do you trust your database?). > > So we implemented an encrypted key-value store. The encrypted key value > store encrypts at the moment only the value of the stored key-value pair. > We're working on encrypting the key (=ID) as well. Because you can't trust > the file system of the web-app server as well as the database, the secure > store needs to be initialized with a passphrase or keyfile at the start of > the (web-)application. After initialization the encrypted kv store resides > inside of "@Context HttpServletRequest" and is accessible by the Web-App. > The key for de/encryption only resides inside the memory of the server. > This is the big win - even if you get a database dump (and there are *a > lot* of dumps on pastebin or in the darknet) you wont be able to decrypt > the stored values. Also, if you get access to the file system - you wont be > able to decipher the values. > > The Class of the Encrypted Key Value store only lets you initialize it > with a passphrase, but never read the passphrase nor the symmetric key. > Nevertheless there is no perfect security: If an attacker obtains full root > access to the web application server he will be able to get access to the > keys by dumping the memory of the JVM. Also if there is an code execution > weakness you might be able to obtain values - we counter measure that by > using Java Security Manager. Only signed classes can will get access to the > Encrypted Key Value Store. Also we set up a restriction on reflections. > > Now my request/question: Do you think it would make sense to add an > annotation "@Encrypted" to encrypt fields at ORM Level? In my opinion this > would be a great security win for hibernate (even if the JPA doesn't define > an "Encrypted Entity"). It would be very nice if you just annotate a field > with "@Encrypted" and let a transparent encryption do the work. > > There are several steps to archive this, but I think it is possible: > * Each entity needs an Initialization Vector > * It is possible to make use of "format preserving encryption" and > therefore not breaking the schema with encryption > * Without format preserving encryption, the encrypted fields will be > converted to an @Lob or at least some binary type > * The initialization of the application needs to be done by an user - > there is no generic way to archive this without breaking the security > > If you think that might be a good thing for hibernate, please advice were > it should be implemented and I will try to do so. > > > Kind regards > Sebastian Bicchi > > -------------------------------------------------- > Sec-Research GmbH > Graf Starhemberggasse 6/4 > 1040 Vienna > Tel.: +43 (0)660/228 25 77 > https://www.sec-research.com > FN445069p, Handelsgericht Wien > -------------------------------------------------- > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
