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 <tom...@olafkock.de>:
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
--
Mit freundlichen Grüßen
Carsten Klein
mail: c.kl...@datagis.com [mailto:c.kl...@datagis.com]
----------------------------------------------------------------------------
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: i...@datagis.com
Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein
Amtsgericht Stuttgart, HRB 225945
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
