DISQUS

Erlend · 3 years ago

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.

Johannes Brodwall · 3 years ago

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 · 2 years ago

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.

Johannes Brodwall · 2 years ago

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 · 2 years ago

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.

Johannes Brodwall · 2 years ago

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 · 2 years ago

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.

Johannes Brodwall · 2 years ago

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.