Before we go ahead and add the decrypt feature, would the maintainers of e.g. PAX JDBC etc be interested in adding support for this in their services?


Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards,

Alex Weirig
Responsable Technique

Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco L - 2623 LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> Tel: +352 4796 - 6127 Fax: +352 42 88 81 www.technolink.lu <http://www.technolink.lu>

On 19/02/2018 14:03, Jean-Baptiste Onofré wrote:
Yes, that would work but it requires:

1. either a change at ConfigAdmin layer (difficult and not accurate IMHO)
2. a Karaf service that application (like Pax JDBC) can leverage when a
{CRYPT}hash{CRYPT} property value pattern is detected.

Karaf JAAS already has EncryptionService providing encryption only. We have two
implementation of this service:
- Basic (BasicEncryptionService)
- Jasypt (JasyptEncryptionService)

I can extend the EncryptionService to also provide decrypt and check.

Regards
JB

On 02/19/2018 01:56 PM, Alex Weirig wrote:
That's correct and that's what I'm trying to solve (or work around).

E.g.

I need to store my mysql password in the config file. The password is 1234pwd.

Imagine we have a karaf command that's config:encrypt.

I use config:encrypt 1234pwd and it returns a hash, this hash would computed
using a master password that would be different for each karaf instance based on
it's "environment".

Now when ConfigAdmin reads the configuration file it will know how to compute
the master password and decrypt the password and use the decrypted password
(1234pwd) with the datasource or JDBC connection.

Since there would be no "API" to do this decryption "by hand" nobody would
"easily" be able to get access to the decrypted password.

I'm currently looking if each karaf instance has some kind of a GUID or if there
is some kind of GUID available from the system or something else that could be
used to compute the instance related master password.

So basically the idea is to make the decryption "configuration" a system 
feature?

Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards,

Alex Weirig
Responsable Technique

Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco L - 2623
LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> Tel:
+352 4796 - 6127 Fax: +352 42 88 81 www.technolink.lu <http://www.technolink.lu>

On 19/02/2018 13:44, Jean-Baptiste Onofré wrote:
Hi Alex,

The problem is the "direction".

Let me take an example: the encryption service we have to crypt passwords in
etc/users.properties.
Here's the direction is pretty simple: the user provides the password, we
encrypt the password using the configuration defined in
etc/org.apache.karaf.jaas.cfg and we compare the hashes: if the hash is the same
as the one contained in the etc/users.properties, then, it's OK.

But the user provides his password.

In any cfg configurations, it's the opposite: the application (let's say
pax-jdbc or your own application) expects the property value in clear text
whereas it's stored encrypted. So, it means that somehow we have to start from
the encrypted property value to provide the clear text one.
For instance, you are using pax-jdbc for datasources. You want to store the
database password encrypted in the cfg file. However, to actually establish the
connection, we have to use the password in clear text. So, we have to decrypt.

So a generic solution at ConfigAdmin layer would require decrypt->clear
direction which obviously require the decryption "configuration".

Regards
JB

On 02/19/2018 01:31 PM, Alex Weirig wrote:
Hi Jean-Baptiste,

that sounds like an interesting idea but you are pointing at an obvious drawback
with these solutions...

If we're using a "master password" (like jasypt) we need to provide this master
password in order to allow decryption of the password. That master password has
to be available in clear text but then, at the end of day you're only protecting
your environment against "hackers" that are able to "hack" you systems but "too
stupid" to decrypt the password using the master password.

Possibly storing the password in a file with limited ownership access rights
might help a little bit but if the hacker has (root) access he will get around
that too.

I was thinking if it would be possible to create a "karaf password encryption
feature" where each karaf instance would have it's own computable (since we
can't store it) "master password" (maybe based on a machine identifier) and
would allow you to encrypt the password but there would be no "API or utility"
to allow the user to decrypt the password.

Now the "hacker" would need more knowledge to get access to the passwords ...

Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards,

Alex Weirig
Responsable Technique

Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco L - 2623
LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> Tel:
+352 4796 - 6127 Fax: +352 42 88 81 www.technolink.lu <http://www.technolink.lu>

On 19/02/2018 08:03, Jean-Baptiste Onofré wrote:
Hi Alex,

We can imagine to add a feature that detect property values with a pattern
(for instance {CRYPT}hash{CRYPT}) and decrypt the value (so it has to be a
symetric encryption to allow to decrypt).

I already thought about a Karaf ConfigAdmin "interceptor" to do that. But it
has to be at ConfigAdmin level to be reliable.

Jasypt works that way assuming you are in blueprint (it provides a blueprint
specific namespace that decrypt the property values at blueprint:cm level).

Regards
JB

On 19/02/2018 07:52, Alex Weirig wrote:
Thank you very much to everybody who responded to my question.

I will have a look at your recommended approaches.

Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards,

Alex Weirig
Responsable Technique

Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco L - 2623
LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> Tel:
+352 4796 - 6127 Fax: +352 42 88 81 www.technolink.lu <http://www.technolink.lu>

On 10/02/2018 21:06, Jean-Baptiste Onofré wrote:
True, but jasypt namespace is blueprint specific.

Outside of blueprint (directly in ConfigAdmin), you have to use your own
wrapper.

Regards
JB

On 02/10/2018 05:32 PM, Ryan Moquin wrote:
You can still put the placeholders in a config file without using
blueprint, but
you need them injected into something that will resolve those
placeholders.  In
this case, the only thing I can suggest offhand (and it's not hard), would
be to
use a Configuration listener (I think that's the name of the interface,
it's for
listening to when. PID is available in configuration admin), then when your
config becomes available, you check for the encrypted properties and decrypt
them.  You'd have to retrieve the encryption service via your listener.
That is
probably how Blueprint does it.

Ryan


On Sat, Feb 10, 2018, 9:22 AM Weirig, Alex <alex.wei...@technolink.lu
<mailto:alex.wei...@technolink.lu>> wrote:

      Hello,

      I wonder if there is a way to use the jasypt feature in Karaf 4.1.4 to
      encrypt passwords in configuration files without having to define the
      placeholders using Blueprint but rather using a cfg file in /etc/?

      All the examples I've found so far are rather "old" and still rely on
      Blueprint ... I'm not using Blueprint at all in my applications and I
would
      appreciate if I didn't have to use it just for this configuration.

      If it was possible to define these placeholders in a cfg file in /etc/ it
      would make things easier ... or is there even an easier way to support
      encrypted properties with the current Karaf releases?

      Thank you very much for your support

      ---

      Schéin Gréiss,
      Mit freundlichen Grüßen,
      Meilleures salutations,
      Kind regards,

      Alex Weirig
      Responsable Technique

      Ville de Luxembourg - Centre Technolink
      2, rue Charles de Tornaco
<https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g>
      L - 2623 LUXEMBOURG
      alex.wei...@technolink.lu  <mailto:alex.wei...@technolink.lu>

      Tel: +352 4796 - 6127
      Fax: +352 42 88 81
      www.technolink.lu  <http://www.technolink.lu>



Reply via email to