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>
