Add encryption support for PropertyPlaceholderConfigurer [SPR-10666]

[spring-projects-issues]

Michael Isvy opened SPR-10666 and commented

At this stage, Spring does not provide support for encrypted property values.

For instance, if I externalize my values in a properties file using a property-placeholder, I can only have the following inside my properties file:

jdbc.username=admin
jdbc.password=secret

I would like to be able to use the following instead:

jdbc.username=admin
jdbc.password={md5}bface9aa8e675d3a1757f143893793db

(syntax is just a draft, you might find something more appropriate)

We could have a new class that inherits from PropertyPlaceholderConfigurer and adds the encryption features.

And we could add a property to the namespace as follows:

<context:property-placeholder useEncryption="true" location="classpath:spring/data-access.properties"/>

( 'useEncryption' could default to true or false depending on what you find more appropriate).

---

Issue Links:

• PropertySourcesPlaceholderConfigurer never calls "convertProperties" on merged properties [SPR-8928] #13568 PropertySourcesPlaceholderConfigurer never calls "convertProperties" on merged properties
• Allow the use of custom PropertySource annotations in @Configuration classes [SPR-8963] #13603 Allow the use of custom PropertySource annotations in @Configuration classes
• SEC-3123 Encrypted property value support
• Backport encrypted property functionality from spring-cloud-config environment work [SPR-12635] #17236 Backport encrypted property functionality from spring-cloud-config environment work

2 votes, 11 watchers

[spring-projects-issues]

Phil Webb commented

One problem with this type of encryption is that we need to decrypt the property values before they can be used. This means we would need some way to configure a master key. We also would also need to use a symmetric encryption algorithm (such as DES). Your example above shows an MD5 hash being used as the value, this can work in challenge-response scenarios, but I don't think it will work for property values as we will have no way of getting back the original value.

Another inherent weakness with this type of scheme is that the properties file and application are usually co-located, meaning that an attacker would effectively have access to key by unpacking the jar (and possibly decompiling some .class file).

[spring-projects-issues]

Michael Isvy commented

Hi Phil,
I was just thinking we can do something similar to what we have already in place in Spring Security (which is why I used that syntax).
Unless you see any issue there?

[spring-projects-issues]

Phil Webb commented

I am not familiar with that, can you point me at an example?

[spring-projects-issues]

Michael Isvy commented

Sure!
You can check here for instance:
http://www.mkyong.com/spring-security/spring-security-password-hashing-example/

I thought that Spring Security was using a prefix such as {MD5} but that's not needed.

[spring-projects-issues]

Phil Webb commented

robwinch can probably chime in here but I assume this is only possible in Spring Security because this is testing against user entered input.

e.g:

• User types 'password'
• A SHA1 of 'password' is created
• The SHA1 can be compared to the value in the configuration

The problem is that there is no way to get back to 'password' if you only have the SHA1.

[spring-projects-issues]

Michael Isvy commented

Actually, Jasypt seems to offer exactly that :).
www.jasypt.org/api/jasypt/1.8/org/jasypt/spring/properties/EncryptablePropertyPlaceholderConfigurer.html

(adding Daniel who is the creator of Jasypt)
Daniel Fernández

[spring-projects-issues]

Daniel Fernández commented

Yup, Jasypt can do that.

In fact, in version 1.9 I even added a Spring namespace so that these encrypting structures can be declared like:

<encryption:encryptable-property-placeholder encryptor="stringEnc" location="classpath:application.properties"/>

...or even directly an encrypted .properties file (equivalent to "util:properties") like:

<encryption:encryptable-properties encryptor="stringEnc" location="classpath:application.properties"/>

Of course in both cases you will have to first declare and configure that "stringEnc" bean, which is the encryptor object in charge of encrypting/decrypting properties in those files.

See more info here: http://www.jasypt.org/spring31.html

[spring-projects-issues]

Rob Winch commented

Encryption can be done (as is done in Jasypt), but one way hashes such as SHA1 cannot be done in this case for the reasons Phil mentioned. In the past when such use cases needed to be addressed I have always recommended Jasypt as IMHO it is an exceptional library.

If Daniel is interested, perhaps we can collaborate to see if/how we could get first class support in Spring Security.

[spring-projects-issues]

Phil Webb commented

Recommending the use of Jasypt or possibly adding first class support to Spring Security seems like the best option here. The core framework classes are flexible enough to support the feature and I think it would be best not to add too much more to the core.

I will leave this as "Contributions Welcome" and see how many votes we get.

[spring-projects-issues]

Daniel Fernández commented

Well... if you have any specific ideas regarding jasypt integration in the future, I'll be happy to discuss them with you :-)

[spring-projects-issues]

Sam Brannen commented

Please note that this is related to the following issues.

• SEC-3123
• Allow the use of custom PropertySource annotations in @Configuration classes [SPR-8963] #13603
• PropertySourcesPlaceholderConfigurer never calls "convertProperties" on merged properties [SPR-8928] #13568
• Backport encrypted property functionality from spring-cloud-config environment work [SPR-12635] #17236

[spring-projects-issues]

Rob Winch commented

I think at this point this issue is a duplicate of SEC-3123.

[spring-projects-issues]

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.