How to encrypt db password in tomcat context.xml

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

How to encrypt db password in tomcat context.xml

FANG YAP
Hi Tomcat,

I would like to know how to encrypt and decrypt the database password in
context.xml when the application is running which also allow me to change
the db password for the purpose of security.

Database driver is Oracle
JDK: 1.8.0_251
Tomcat Version: 8.5.55


Appreciate ya help.

Rgs,
FanggDev.
Reply | Threaded
Open this post in threaded view
|

Re: How to encrypt db password in tomcat context.xml

Olaf Kock

On 26.06.20 15:05, FANG YAP wrote:
> Hi Tomcat,
>
> I would like to know how to encrypt and decrypt the database password in
> context.xml when the application is running which also allow me to change
> the db password for the purpose of security.


https://cwiki.apache.org/confluence/display/TOMCAT/Password




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to encrypt db password in tomcat context.xml

Jürgen Weber
> https://cwiki.apache.org/confluence/display/TOMCAT/Password

Well, I know a chief open source app server that has the password to
decrypt all passwords buried in its open source, and I know auditors
who are good if root cannot read passwords at first sight. The
reasoning behind that is that running java -jar someappserverlib.jar
-decrypt is a deliberate act that a god guy root does not do. So a
hidden password is a step better, even if not in the cryptographic
sense.

Am Fr., 26. Juni 2020 um 15:25 Uhr schrieb Olaf Kock <[hidden email]>:

>
>
> On 26.06.20 15:05, FANG YAP wrote:
> > Hi Tomcat,
> >
> > I would like to know how to encrypt and decrypt the database password in
> > context.xml when the application is running which also allow me to change
> > the db password for the purpose of security.
>
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Password
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to encrypt db password in tomcat context.xml

Olaf Kock

On 28.06.20 19:50, Jürgen Weber wrote:

>>>> I would like to know how to encrypt and decrypt the database password in
>>>> context.xml when the application is running which also allow me to change
>>>> the db password for the purpose of security.
>> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> Well, I know a chief open source app server that has the password to
> decrypt all passwords buried in its open source, and I know auditors
> who are good if root cannot read passwords at first sight. The
> reasoning behind that is that running java -jar someappserverlib.jar
> -decrypt is a deliberate act that a god guy root does not do. So a
> hidden password is a step better, even if not in the cryptographic
> sense.

Hi Jürgen,

I don't get your point here. Are you arguing that the linked wiki
article is incorrect, insufficient or invalid?

Because I believe that the article documents how to implement everything
that you describe on your own, and gives arguments for why this is not
implemented out of the box.

Best,

Olaf




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to encrypt db password in tomcat context.xml

Jürgen Weber
I'd just put some nice password as byte[] into Tomcat's source code
and provide a way to have passwords in the configs encrypted with that
nice password.

> Use properties replacement so that in the xml config you have ${db.password} and in conf/catalina.properties you put the password there.

So one could have samething like db.pass=3des:<somehexbytes> in
catalina.properties

Greetings, Juergen

Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock <[hidden email]>:

>
>
> On 28.06.20 19:50, Jürgen Weber wrote:
> >>>> I would like to know how to encrypt and decrypt the database password in
> >>>> context.xml when the application is running which also allow me to change
> >>>> the db password for the purpose of security.
> >> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> > Well, I know a chief open source app server that has the password to
> > decrypt all passwords buried in its open source, and I know auditors
> > who are good if root cannot read passwords at first sight. The
> > reasoning behind that is that running java -jar someappserverlib.jar
> > -decrypt is a deliberate act that a god guy root does not do. So a
> > hidden password is a step better, even if not in the cryptographic
> > sense.
>
> Hi Jürgen,
>
> I don't get your point here. Are you arguing that the linked wiki
> article is incorrect, insufficient or invalid?
>
> Because I believe that the article documents how to implement everything
> that you describe on your own, and gives arguments for why this is not
> implemented out of the box.
>
> Best,
>
> Olaf
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to encrypt db password in tomcat context.xml

Carsten Klein
Hi Jürgen and Olaf,

I can really understand Jürgen's intentions. The core problem is not
security but administrators and so called security panels in
"professional" (non-open source related) companies. I really know this
from my own experiences. Maybe that's a German problem, since Germans
are said to be over-correct? Sometimes, that turns into paranoia...
(I'm from Germany, so I know this circumstances quite well, sounds
like Jürgen is German as well...)

True is, that there are administrators, which have very little
knowledge of software in general and security. Those tend to stick to
their personal categorical rules, which often are far off from what is
considered sensible by real IT and software professionals.
Furthermore, there are "security" panels, working out policies for a
company. These often only consist of people with very little *real* IT
an security knowledge.

The (sad) point is, that the policies passed by such a council are
actually valid and no one ever again asks whether these make sense or
are *correct* from a security professional's point of view. Changing
user passwords on a regular basis (e.g. after 90 days) still today is
one prominent example of that.

So, in order to make Tomcat fit into such "professional" company
environments easily (w/o requiring people to implement their own data
source class), it may be a good idea to add such a "encrypted
password" feature to Tomcat. Consider this as pure "syntactic sugar"
and keep in mind, that it's NOT a security feature (need to emphasis
that in the docs).

My idea is, that *all* passwords read by Tomcat MAY be
encrypted/obfuscated with a small number of algorithms. The algorithm
applied to the password could be prefixed like Jürgen suggested:

password="+duk6<7v@LD#"                    (plain, no encryption)
password="base64:K2R1azY8N3ZATEQj"         (base64 obfuscation)
password="3des:hkph5ewjEwv70CvTB16v/w=="   (3DES with hard-coded key,
expressed as base64 string)

The decoding algorithm could be implemented in a common util method
String decodePassword(String password) in Tomcat, so it could easily
be called from all those places at which Tomcat actually reads a
password.

Also, a small separate tool should be provided, which encodes such
passwords (like htpasswd does for httpd). However, it should be
sufficient to just print the encoded password to standard out. Then,
the user is responsible for copy and pasting it into the config file.

I offer my help for writing such an enhancement, since I believe that
it's a way to make Tomcat more out-of-the-box usable in such
"professional" company's environments (for some people it may be the
only way).

Again, I know this is NOT a security feature as it adds no extra
security to Tomcat. However, I may make some administrators and CEOs
happy, that are solely guided by questionable policies they don't
understand.

Some ideas on that?

Carsten


On 28.06.2020 23:49, Jürgen Weber wrote:

> I'd just put some nice password as byte[] into Tomcat's source code
> and provide a way to have passwords in the configs encrypted with that
> nice password.
>
>> Use properties replacement so that in the xml config you have
>> ${db.password} and in conf/catalina.properties you put the password
>> there.
>
> So one could have samething like db.pass=3des:<somehexbytes> in
> catalina.properties
>
> Greetings, Juergen
>
> Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock <[hidden email]>:
>>
>>
>> On 28.06.20 19:50, Jürgen Weber wrote:
>> >>>> I would like to know how to encrypt and decrypt the database
>> password in
>> >>>> context.xml when the application is running which also allow
>> me to change
>> >>>> the db password for the purpose of security.
>> >> https://cwiki.apache.org/confluence/display/TOMCAT/Password
>> > Well, I know a chief open source app server that has the password to
>> > decrypt all passwords buried in its open source, and I know auditors
>> > who are good if root cannot read passwords at first sight. The
>> > reasoning behind that is that running java -jar someappserverlib.jar
>> > -decrypt is a deliberate act that a god guy root does not do. So a
>> > hidden password is a step better, even if not in the cryptographic
>> > sense.
>>
>> Hi Jürgen,
>>
>> I don't get your point here. Are you arguing that the linked wiki
>> article is incorrect, insufficient or invalid?
>>
>> Because I believe that the article documents how to implement everything
>> that you describe on your own, and gives arguments for why this is not
>> implemented out of the box.
>>
>> Best,
>>
>> Olaf
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


--
--


Mit freundlichen Grüßen

Carsten Klein

mail: [hidden email]   [mailto:[hidden email]]

----------------------------------------------------------------------------
DataGis GmbH    2&3dimensionale
                 Informationsverarbeitung
                 und digitale Kartographie

Johann-Strauß-Str. 26   70794 Filderstadt

tel:  +49 (0)7158 940267
fax:  +49 (0)7158 940268
web:  www.datagis.com
mail: [hidden email]

Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein
Amtsgericht Stuttgart, HRB 225945

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to encrypt db password in tomcat context.xml

Rémy Maucherat
On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein <[hidden email]> wrote:

> Hi Jürgen and Olaf,
>
> I can really understand Jürgen's intentions. The core problem is not
> security but administrators and so called security panels in
> "professional" (non-open source related) companies. I really know this
> from my own experiences. Maybe that's a German problem, since Germans
> are said to be over-correct? Sometimes, that turns into paranoia...
> (I'm from Germany, so I know this circumstances quite well, sounds
> like Jürgen is German as well...)
>
> True is, that there are administrators, which have very little
> knowledge of software in general and security. Those tend to stick to
> their personal categorical rules, which often are far off from what is
> considered sensible by real IT and software professionals.
> Furthermore, there are "security" panels, working out policies for a
> company. These often only consist of people with very little *real* IT
> an security knowledge.
>
> The (sad) point is, that the policies passed by such a council are
> actually valid and no one ever again asks whether these make sense or
> are *correct* from a security professional's point of view. Changing
> user passwords on a regular basis (e.g. after 90 days) still today is
> one prominent example of that.
>
> So, in order to make Tomcat fit into such "professional" company
> environments easily (w/o requiring people to implement their own data
> source class), it may be a good idea to add such a "encrypted
> password" feature to Tomcat. Consider this as pure "syntactic sugar"
> and keep in mind, that it's NOT a security feature (need to emphasis
> that in the docs).
>
> My idea is, that *all* passwords read by Tomcat MAY be
> encrypted/obfuscated with a small number of algorithms. The algorithm
> applied to the password could be prefixed like Jürgen suggested:
>
> password="+duk6<7v@LD#"                    (plain, no encryption)
> password="base64:K2R1azY8N3ZATEQj"         (base64 obfuscation)
> password="3des:hkph5ewjEwv70CvTB16v/w=="   (3DES with hard-coded key,
> expressed as base64 string)
>
> The decoding algorithm could be implemented in a common util method
> String decodePassword(String password) in Tomcat, so it could easily
> be called from all those places at which Tomcat actually reads a
> password.
>
> Also, a small separate tool should be provided, which encodes such
> passwords (like htpasswd does for httpd). However, it should be
> sufficient to just print the encoded password to standard out. Then,
> the user is responsible for copy and pasting it into the config file.
>
> I offer my help for writing such an enhancement, since I believe that
> it's a way to make Tomcat more out-of-the-box usable in such
> "professional" company's environments (for some people it may be the
> only way).
>
> Again, I know this is NOT a security feature as it adds no extra
> security to Tomcat. However, I may make some administrators and CEOs
> happy, that are solely guided by questionable policies they don't
> understand.
>
> Some ideas on that?
>

The Tomcat committers' decision has always been to block inclusion of such
a feature, for the reasons explained in the wiki page here
https://cwiki.apache.org/confluence/display/TOMCAT/Password
As a result, your proposal will not be considered.

If you want a ready to use tool, go here:
https://github.com/web-servers/tomcat-vault

Rémy


>
> Carsten
>
>
> On 28.06.2020 23:49, Jürgen Weber wrote:
> > I'd just put some nice password as byte[] into Tomcat's source code
> > and provide a way to have passwords in the configs encrypted with that
> > nice password.
> >
> >> Use properties replacement so that in the xml config you have
> >> ${db.password} and in conf/catalina.properties you put the password
> >> there.
> >
> > So one could have samething like db.pass=3des:<somehexbytes> in
> > catalina.properties
> >
> > Greetings, Juergen
> >
> > Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock <[hidden email]
> >:
> >>
> >>
> >> On 28.06.20 19:50, Jürgen Weber wrote:
> >> >>>> I would like to know how to encrypt and decrypt the database
> >> password in
> >> >>>> context.xml when the application is running which also allow
> >> me to change
> >> >>>> the db password for the purpose of security.
> >> >> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> >> > Well, I know a chief open source app server that has the password to
> >> > decrypt all passwords buried in its open source, and I know auditors
> >> > who are good if root cannot read passwords at first sight. The
> >> > reasoning behind that is that running java -jar someappserverlib.jar
> >> > -decrypt is a deliberate act that a god guy root does not do. So a
> >> > hidden password is a step better, even if not in the cryptographic
> >> > sense.
> >>
> >> Hi Jürgen,
> >>
> >> I don't get your point here. Are you arguing that the linked wiki
> >> article is incorrect, insufficient or invalid?
> >>
> >> Because I believe that the article documents how to implement everything
> >> that you describe on your own, and gives arguments for why this is not
> >> implemented out of the box.
> >>
> >> Best,
> >>
> >> Olaf
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
> --
> --
>
>
> Mit freundlichen Grüßen
>
> Carsten Klein
>
> mail: [hidden email]   [mailto:[hidden email]]
>
>
> ----------------------------------------------------------------------------
> DataGis GmbH    2&3dimensionale
>                  Informationsverarbeitung
>                  und digitale Kartographie
>
> Johann-Strauß-Str. 26   70794 Filderstadt
>
> tel:  +49 (0)7158 940267
> fax:  +49 (0)7158 940268
> web:  www.datagis.com
> mail: [hidden email]
>
> Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein
> Amtsgericht Stuttgart, HRB 225945
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

RE: How to encrypt db password in tomcat context.xml

jonmcalexander
-----Original Message-----
From: Rémy Maucherat <[hidden email]>
Sent: Monday, June 29, 2020 1:58 AM
To: Tomcat Users List <[hidden email]>
Subject: Re: How to encrypt db password in tomcat context.xml

On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein <[hidden email]> wrote:

> Hi Jürgen and Olaf,
>
> I can really understand Jürgen's intentions. The core problem is not
> security but administrators and so called security panels in
> "professional" (non-open source related) companies. I really know this
> from my own experiences. Maybe that's a German problem, since Germans
> are said to be over-correct? Sometimes, that turns into paranoia...
> (I'm from Germany, so I know this circumstances quite well, sounds
> like Jürgen is German as well...)
>
> True is, that there are administrators, which have very little
> knowledge of software in general and security. Those tend to stick to
> their personal categorical rules, which often are far off from what is
> considered sensible by real IT and software professionals.
> Furthermore, there are "security" panels, working out policies for a
> company. These often only consist of people with very little *real* IT
> an security knowledge.
>
> The (sad) point is, that the policies passed by such a council are
> actually valid and no one ever again asks whether these make sense or
> are *correct* from a security professional's point of view. Changing
> user passwords on a regular basis (e.g. after 90 days) still today is
> one prominent example of that.
>
> So, in order to make Tomcat fit into such "professional" company
> environments easily (w/o requiring people to implement their own data
> source class), it may be a good idea to add such a "encrypted
> password" feature to Tomcat. Consider this as pure "syntactic sugar"
> and keep in mind, that it's NOT a security feature (need to emphasis
> that in the docs).
>
> My idea is, that *all* passwords read by Tomcat MAY be
> encrypted/obfuscated with a small number of algorithms. The algorithm
> applied to the password could be prefixed like Jürgen suggested:
>
> password="+duk6<7v@LD#"                    (plain, no encryption)
> password="base64:K2R1azY8N3ZATEQj"         (base64 obfuscation)
> password="3des:hkph5ewjEwv70CvTB16v/w=="   (3DES with hard-coded key,
> expressed as base64 string)
>
> The decoding algorithm could be implemented in a common util method
> String decodePassword(String password) in Tomcat, so it could easily
> be called from all those places at which Tomcat actually reads a
> password.
>
> Also, a small separate tool should be provided, which encodes such
> passwords (like htpasswd does for httpd). However, it should be
> sufficient to just print the encoded password to standard out. Then,
> the user is responsible for copy and pasting it into the config file.
>
> I offer my help for writing such an enhancement, since I believe that
> it's a way to make Tomcat more out-of-the-box usable in such
> "professional" company's environments (for some people it may be the
> only way).
>
> Again, I know this is NOT a security feature as it adds no extra
> security to Tomcat. However, I may make some administrators and CEOs
> happy, that are solely guided by questionable policies they don't
> understand.
>
> Some ideas on that?
>

> The Tomcat committers' decision has always been to block inclusion of such a feature, for the reasons explained in the wiki page
> here https://cwiki.apache.org/confluence/display/TOMCAT/Password
> As a result, your proposal will not be considered.

> If you want a ready to use tool, go here:
> https://github.com/web-servers/tomcat-vault

> Rémy

I have been working with the tomcat-vault and so far am finding it promising. One caveat with this, is you can't set variables in the catalina.properties that pull the values from the vault, it only works in xml files, so you have to reference the vault item in server.xml, context.xml, etc.

>
> Carsten
>
>
> On 28.06.2020 23:49, Jürgen Weber wrote:
> > I'd just put some nice password as byte[] into Tomcat's source code
> > and provide a way to have passwords in the configs encrypted with
> > that nice password.
> >
> >> Use properties replacement so that in the xml config you have
> >> ${db.password} and in conf/catalina.properties you put the password
> >> there.
> >
> > So one could have samething like db.pass=3des:<somehexbytes> in
> > catalina.properties
> >
> > Greetings, Juergen
> >
> > Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock
> ><[hidden email]
> >:
> >>
> >>
> >> On 28.06.20 19:50, Jürgen Weber wrote:
> >> >>>> I would like to know how to encrypt and decrypt the database
> >> password in
> >> >>>> context.xml when the application is running which also allow
> >> me to change
> >> >>>> the db password for the purpose of security.
> >> >> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> >> > Well, I know a chief open source app server that has the password
> >> > to decrypt all passwords buried in its open source, and I know
> >> > auditors who are good if root cannot read passwords at first
> >> > sight. The reasoning behind that is that running java -jar
> >> > someappserverlib.jar -decrypt is a deliberate act that a god guy
> >> > root does not do. So a hidden password is a step better, even if
> >> > not in the cryptographic sense.
> >>
> >> Hi Jürgen,
> >>
> >> I don't get your point here. Are you arguing that the linked wiki
> >> article is incorrect, insufficient or invalid?
> >>
> >> Because I believe that the article documents how to implement
> >> everything that you describe on your own, and gives arguments for
> >> why this is not implemented out of the box.
> >>
> >> Best,
> >>
> >> Olaf
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
> --
> --
>
>
> Mit freundlichen Grüßen
>
> Carsten Klein
>
> mail: [hidden email]   [mailto:[hidden email]]
>
>
> ----------------------------------------------------------------------------
> DataGis GmbH    2&3dimensionale
>                  Informationsverarbeitung
>                  und digitale Kartographie
>
> Johann-Strauß-Str. 26   70794 Filderstadt
>
> tel:  +49 (0)7158 940267
> fax:  +49 (0)7158 940268
> web:  www.datagis.com
> mail: [hidden email]
>
> Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein
> Amtsgericht Stuttgart, HRB 225945
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>





Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

[hidden email]


This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: How to encrypt db password in tomcat context.xml

Pesonen, Harri
I have implemented a Tomcat vault as well, it is basically a simplified version of

https://github.com/web-servers/tomcat-vault

My version does not have keystore, so it is much easier to use.
It would be great if Tomcat would have this functionality built-in somehow.

-Harri

-----Original Message-----
From: [hidden email] <[hidden email]>
Sent: maanantai 29. kesäkuuta 2020 17.25
To: [hidden email]
Subject: RE: How to encrypt db password in tomcat context.xml

-----Original Message-----
From: Rémy Maucherat <[hidden email]>
Sent: Monday, June 29, 2020 1:58 AM
To: Tomcat Users List <[hidden email]>
Subject: Re: How to encrypt db password in tomcat context.xml

On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein <[hidden email]> wrote:

> Hi Jürgen and Olaf,
>
> I can really understand Jürgen's intentions. The core problem is not
> security but administrators and so called security panels in
> "professional" (non-open source related) companies. I really know this
> from my own experiences. Maybe that's a German problem, since Germans
> are said to be over-correct? Sometimes, that turns into paranoia...
> (I'm from Germany, so I know this circumstances quite well, sounds
> like Jürgen is German as well...)
>
> True is, that there are administrators, which have very little
> knowledge of software in general and security. Those tend to stick to
> their personal categorical rules, which often are far off from what is
> considered sensible by real IT and software professionals.
> Furthermore, there are "security" panels, working out policies for a
> company. These often only consist of people with very little *real* IT
> an security knowledge.
>
> The (sad) point is, that the policies passed by such a council are
> actually valid and no one ever again asks whether these make sense or
> are *correct* from a security professional's point of view. Changing
> user passwords on a regular basis (e.g. after 90 days) still today is
> one prominent example of that.
>
> So, in order to make Tomcat fit into such "professional" company
> environments easily (w/o requiring people to implement their own data
> source class), it may be a good idea to add such a "encrypted
> password" feature to Tomcat. Consider this as pure "syntactic sugar"
> and keep in mind, that it's NOT a security feature (need to emphasis
> that in the docs).
>
> My idea is, that *all* passwords read by Tomcat MAY be
> encrypted/obfuscated with a small number of algorithms. The algorithm
> applied to the password could be prefixed like Jürgen suggested:
>
> password="+duk6<7v@LD#"                    (plain, no encryption)
> password="base64:K2R1azY8N3ZATEQj"         (base64 obfuscation)
> password="3des:hkph5ewjEwv70CvTB16v/w=="   (3DES with hard-coded key,
> expressed as base64 string)
>
> The decoding algorithm could be implemented in a common util method
> String decodePassword(String password) in Tomcat, so it could easily
> be called from all those places at which Tomcat actually reads a
> password.
>
> Also, a small separate tool should be provided, which encodes such
> passwords (like htpasswd does for httpd). However, it should be
> sufficient to just print the encoded password to standard out. Then,
> the user is responsible for copy and pasting it into the config file.
>
> I offer my help for writing such an enhancement, since I believe that
> it's a way to make Tomcat more out-of-the-box usable in such
> "professional" company's environments (for some people it may be the
> only way).
>
> Again, I know this is NOT a security feature as it adds no extra
> security to Tomcat. However, I may make some administrators and CEOs
> happy, that are solely guided by questionable policies they don't
> understand.
>
> Some ideas on that?
>

> The Tomcat committers' decision has always been to block inclusion of such a feature, for the reasons explained in the wiki page
> here https://cwiki.apache.org/confluence/display/TOMCAT/Password
> As a result, your proposal will not be considered.

> If you want a ready to use tool, go here:
> https://github.com/web-servers/tomcat-vault

> Rémy

I have been working with the tomcat-vault and so far am finding it promising. One caveat with this, is you can't set variables in the catalina.properties that pull the values from the vault, it only works in xml files, so you have to reference the vault item in server.xml, context.xml, etc.

>
> Carsten
>
>
> On 28.06.2020 23:49, Jürgen Weber wrote:
> > I'd just put some nice password as byte[] into Tomcat's source code
> > and provide a way to have passwords in the configs encrypted with
> > that nice password.
> >
> >> Use properties replacement so that in the xml config you have
> >> ${db.password} and in conf/catalina.properties you put the password
> >> there.
> >
> > So one could have samething like db.pass=3des:<somehexbytes> in
> > catalina.properties
> >
> > Greetings, Juergen
> >
> > Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock
> ><[hidden email]
> >:
> >>
> >>
> >> On 28.06.20 19:50, Jürgen Weber wrote:
> >> >>>> I would like to know how to encrypt and decrypt the database
> >> password in
> >> >>>> context.xml when the application is running which also allow
> >> me to change
> >> >>>> the db password for the purpose of security.
> >> >> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> >> > Well, I know a chief open source app server that has the password
> >> > to decrypt all passwords buried in its open source, and I know
> >> > auditors who are good if root cannot read passwords at first
> >> > sight. The reasoning behind that is that running java -jar
> >> > someappserverlib.jar -decrypt is a deliberate act that a god guy
> >> > root does not do. So a hidden password is a step better, even if
> >> > not in the cryptographic sense.
> >>
> >> Hi Jürgen,
> >>
> >> I don't get your point here. Are you arguing that the linked wiki
> >> article is incorrect, insufficient or invalid?
> >>
> >> Because I believe that the article documents how to implement
> >> everything that you describe on your own, and gives arguments for
> >> why this is not implemented out of the box.
> >>
> >> Best,
> >>
> >> Olaf
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
> --
> --
>
>
> Mit freundlichen Grüßen
>
> Carsten Klein
>
> mail: [hidden email]   [mailto:[hidden email]]
>
>
> ----------------------------------------------------------------------------
> DataGis GmbH    2&3dimensionale
>                  Informationsverarbeitung
>                  und digitale Kartographie
>
> Johann-Strauß-Str. 26   70794 Filderstadt
>
> tel:  +49 (0)7158 940267
> fax:  +49 (0)7158 940268
> web:  www.datagis.com
> mail: [hidden email]
>
> Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein
> Amtsgericht Stuttgart, HRB 225945
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>





Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

[hidden email]


This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.


B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[
�\�\��][��X��ܚX�P�X�]
�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�\�\��Z[�X�]
�\X�K�ܙ�B�

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: How to encrypt db password in tomcat context.xml

jonmcalexander
I've written my own vadmin.sh and a vadmin.exe file to take the place of the vault.sh/vault.bat file, just to make things easier here. Just starting testing with some of our app teams before determining if we will move forward with it or not.


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

[hidden email]


This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.


-----Original Message-----
From: Pesonen, Harri <[hidden email]>
Sent: Monday, June 29, 2020 10:10 AM
To: Tomcat Users List <[hidden email]>
Subject: RE: How to encrypt db password in tomcat context.xml

I have implemented a Tomcat vault as well, it is basically a simplified version of

https://github.com/web-servers/tomcat-vault

My version does not have keystore, so it is much easier to use.
It would be great if Tomcat would have this functionality built-in somehow.

-Harri

-----Original Message-----
From: [hidden email] <[hidden email]>
Sent: maanantai 29. kesäkuuta 2020 17.25
To: [hidden email]
Subject: RE: How to encrypt db password in tomcat context.xml

-----Original Message-----
From: Rémy Maucherat <[hidden email]>
Sent: Monday, June 29, 2020 1:58 AM
To: Tomcat Users List <[hidden email]>
Subject: Re: How to encrypt db password in tomcat context.xml

On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein <[hidden email]> wrote:

> Hi Jürgen and Olaf,
>
> I can really understand Jürgen's intentions. The core problem is not
> security but administrators and so called security panels in
> "professional" (non-open source related) companies. I really know this
> from my own experiences. Maybe that's a German problem, since Germans
> are said to be over-correct? Sometimes, that turns into paranoia...
> (I'm from Germany, so I know this circumstances quite well, sounds
> like Jürgen is German as well...)
>
> True is, that there are administrators, which have very little
> knowledge of software in general and security. Those tend to stick to
> their personal categorical rules, which often are far off from what is
> considered sensible by real IT and software professionals.
> Furthermore, there are "security" panels, working out policies for a
> company. These often only consist of people with very little *real* IT
> an security knowledge.
>
> The (sad) point is, that the policies passed by such a council are
> actually valid and no one ever again asks whether these make sense or
> are *correct* from a security professional's point of view. Changing
> user passwords on a regular basis (e.g. after 90 days) still today is
> one prominent example of that.
>
> So, in order to make Tomcat fit into such "professional" company
> environments easily (w/o requiring people to implement their own data
> source class), it may be a good idea to add such a "encrypted
> password" feature to Tomcat. Consider this as pure "syntactic sugar"
> and keep in mind, that it's NOT a security feature (need to emphasis
> that in the docs).
>
> My idea is, that *all* passwords read by Tomcat MAY be
> encrypted/obfuscated with a small number of algorithms. The algorithm
> applied to the password could be prefixed like Jürgen suggested:
>
> password="+duk6<7v@LD#"                    (plain, no encryption)
> password="base64:K2R1azY8N3ZATEQj"         (base64 obfuscation)
> password="3des:hkph5ewjEwv70CvTB16v/w=="   (3DES with hard-coded key,
> expressed as base64 string)
>
> The decoding algorithm could be implemented in a common util method
> String decodePassword(String password) in Tomcat, so it could easily
> be called from all those places at which Tomcat actually reads a
> password.
>
> Also, a small separate tool should be provided, which encodes such
> passwords (like htpasswd does for httpd). However, it should be
> sufficient to just print the encoded password to standard out. Then,
> the user is responsible for copy and pasting it into the config file.
>
> I offer my help for writing such an enhancement, since I believe that
> it's a way to make Tomcat more out-of-the-box usable in such
> "professional" company's environments (for some people it may be the
> only way).
>
> Again, I know this is NOT a security feature as it adds no extra
> security to Tomcat. However, I may make some administrators and CEOs
> happy, that are solely guided by questionable policies they don't
> understand.
>
> Some ideas on that?
>

> The Tomcat committers' decision has always been to block inclusion of
> such a feature, for the reasons explained in the wiki page here
> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> As a result, your proposal will not be considered.

> If you want a ready to use tool, go here:
> https://github.com/web-servers/tomcat-vault

> Rémy

I have been working with the tomcat-vault and so far am finding it promising. One caveat with this, is you can't set variables in the catalina.properties that pull the values from the vault, it only works in xml files, so you have to reference the vault item in server.xml, context.xml, etc.

>
> Carsten
>
>
> On 28.06.2020 23:49, Jürgen Weber wrote:
> > I'd just put some nice password as byte[] into Tomcat's source code
> > and provide a way to have passwords in the configs encrypted with
> > that nice password.
> >
> >> Use properties replacement so that in the xml config you have
> >> ${db.password} and in conf/catalina.properties you put the password
> >> there.
> >
> > So one could have samething like db.pass=3des:<somehexbytes> in
> > catalina.properties
> >
> > Greetings, Juergen
> >
> > Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock
> ><[hidden email]
> >:
> >>
> >>
> >> On 28.06.20 19:50, Jürgen Weber wrote:
> >> >>>> I would like to know how to encrypt and decrypt the database
> >> password in
> >> >>>> context.xml when the application is running which also allow
> >> me to change
> >> >>>> the db password for the purpose of security.
> >> >> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> >> > Well, I know a chief open source app server that has the password
> >> > to decrypt all passwords buried in its open source, and I know
> >> > auditors who are good if root cannot read passwords at first
> >> > sight. The reasoning behind that is that running java -jar
> >> > someappserverlib.jar -decrypt is a deliberate act that a god guy
> >> > root does not do. So a hidden password is a step better, even if
> >> > not in the cryptographic sense.
> >>
> >> Hi Jürgen,
> >>
> >> I don't get your point here. Are you arguing that the linked wiki
> >> article is incorrect, insufficient or invalid?
> >>
> >> Because I believe that the article documents how to implement
> >> everything that you describe on your own, and gives arguments for
> >> why this is not implemented out of the box.
> >>
> >> Best,
> >>
> >> Olaf
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
> --
> --
>
>
> Mit freundlichen Grüßen
>
> Carsten Klein
>
> mail: [hidden email]   [mailto:[hidden email]]
>
>
> ----------------------------------------------------------------------------
> DataGis GmbH    2&3dimensionale
>                  Informationsverarbeitung
>                  und digitale Kartographie
>
> Johann-Strauß-Str. 26   70794 Filderstadt
>
> tel:  +49 (0)7158 940267
> fax:  +49 (0)7158 940268
> web:  www.datagis.com
> mail: [hidden email]
>
> Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein
> Amtsgericht Stuttgart, HRB 225945
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>





Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

[hidden email]


This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.


B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB  [  X  ܚX KK[XZ[
 \ \  ][  X  ܚX P X ]
 \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 \ \  Z[ X ]
 \X K ܙ B
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB  [  X  ܚX KK[XZ[
 \ \  ][  X  ܚX P X ]
 \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 \ \  Z[ X ]
 \X K ܙ B

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]