On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein <c.kl...@datagis.com> 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 <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 > >
