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/encryp...
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-...
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.bicchi(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev