Using jasypt in Karaf 4.1.4 without Blueprint?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Using jasypt in Karaf 4.1.4 without Blueprint?

Alex Weirig
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
L - 2623 LUXEMBOURG

Tel: +352 4796 - 6127
Fax: +352 42 88 81
www.technolink.lu


Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

rkmoquin

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 <[hidden email]> 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
L - 2623 LUXEMBOURG

Tel: +352 4796 - 6127
Fax: +352 42 88 81
www.technolink.lu


Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

jbonofre
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 <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>
>     Tel: +352 4796 - 6127
>     Fax: +352 42 88 81
>     www.technolink.lu <http://www.technolink.lu>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

Alex Weirig

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
[hidden email]
Tel: +352 4796 - 6127
Fax: +352 42 88 81
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 <[hidden email]
[hidden email]> 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
    [hidden email] [hidden email]

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



    

Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

jbonofre
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 [hidden email]
> <mailto:[hidden email]> 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 <[hidden email]
>>> <mailto:[hidden email]>> 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
>>>      [hidden email]  <mailto:[hidden email]>
>>>
>>>      Tel: +352 4796 - 6127
>>>      Fax: +352 42 88 81
>>>      www.technolink.lu  <http://www.technolink.lu>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

Alex Weirig

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
[hidden email]
Tel: +352 4796 - 6127
Fax: +352 42 88 81
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 [hidden email] [hidden email] 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 <[hidden email]
[hidden email]> 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
     [hidden email]  [hidden email]

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




Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

jbonofre
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 [hidden email] <mailto:[hidden email]> 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 [hidden email] <mailto:[hidden email]> 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 <[hidden email]
>>>>> <mailto:[hidden email]>> 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
>>>>>      [hidden email]  <mailto:[hidden email]>
>>>>>
>>>>>      Tel: +352 4796 - 6127
>>>>>      Fax: +352 42 88 81
>>>>>      www.technolink.lu  <http://www.technolink.lu>
>>>>>
>>>>>
>>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

Alex Weirig

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
[hidden email]
Tel: +352 4796 - 6127
Fax: +352 42 88 81
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 [hidden email] [hidden email] 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 [hidden email] [hidden email] 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 <[hidden email]
[hidden email]> 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
     [hidden email]  [hidden email]

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



          

      

    

Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

jbonofre
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 [hidden email] <mailto:[hidden email]> 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 [hidden email] <mailto:[hidden email]> 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 [hidden email] <mailto:[hidden email]> 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 <[hidden email]
>>>>>>> <mailto:[hidden email]>> 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
>>>>>>>      [hidden email]  <mailto:[hidden email]>
>>>>>>>
>>>>>>>      Tel: +352 4796 - 6127
>>>>>>>      Fax: +352 42 88 81
>>>>>>>      www.technolink.lu  <http://www.technolink.lu>
>>>>>>>
>>>>>>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

Alex Weirig

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
[hidden email]
Tel: +352 4796 - 6127
Fax: +352 42 88 81
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 [hidden email] [hidden email] 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 [hidden email] [hidden email] 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 [hidden email] [hidden email] 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 <[hidden email]
[hidden email]> 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
     [hidden email]  [hidden email]

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



      

    

Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

jbonofre
As most of Karaf committers are also Pax * projects contributors, I think it's a
fair request.

However, Pax JDBC already provides such feature: it's part of pax-jdbc-config
already (in the DataSourceConfigManager). It uses an embedded encryption service
(not the one provided by Karaf), but it's basically what you need.

My point was more for your application or finding a generic way.

Regards
JB

On 02/19/2018 03:05 PM, Alex Weirig wrote:

> 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 [hidden email] <mailto:[hidden email]> 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 [hidden email] <mailto:[hidden email]> 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 [hidden email] <mailto:[hidden email]> 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 [hidden email] <mailto:[hidden email]> 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 <[hidden email]
>>>>>>>>> <mailto:[hidden email]>> 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
>>>>>>>>>      [hidden email]  <mailto:[hidden email]>
>>>>>>>>>
>>>>>>>>>      Tel: +352 4796 - 6127
>>>>>>>>>      Fax: +352 42 88 81
>>>>>>>>>      www.technolink.lu  <http://www.technolink.lu>
>>>>>>>>>
>>>>>>>>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Using jasypt in Karaf 4.1.4 without Blueprint?

Alex Weirig

OK then it might make sense to add the decrypt 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
L - 2623 LUXEMBOURG
[hidden email]
Tel: +352 4796 - 6127
Fax: +352 42 88 81
www.technolink.lu

On 19/02/2018 15:20, Jean-Baptiste Onofré wrote:
As most of Karaf committers are also Pax * projects contributors, I think it's a
fair request.

However, Pax JDBC already provides such feature: it's part of pax-jdbc-config
already (in the DataSourceConfigManager). It uses an embedded encryption service
(not the one provided by Karaf), but it's basically what you need.

My point was more for your application or finding a generic way.

Regards
JB

On 02/19/2018 03:05 PM, Alex Weirig wrote:
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 [hidden email] [hidden email] 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 [hidden email] [hidden email] 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 [hidden email] [hidden email] 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 [hidden email] [hidden email] 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 <[hidden email]
[hidden email]> 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
     [hidden email]  [hidden email]

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