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>
>>>>>
>>>>>
>>>
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to