Chuck,
On 8/3/24 12:17, Chuck Caldarale wrote:
On Aug 3, 2024, at 06:28, MOHAMMED Bahauddin N
<bahauddin.moham...@hexagon.com.INVALID> wrote:
I have a request related to the Keystore password in Apache
Tomcat's 'server.xml' file. Currently, the password under the
Connector port is displayed in plain text,
Displayed to whom?
which is a security concern.
No, it’s not - as long as you have properly secured the Tomcat
configuration files. They should be accessible only by the userid
Tomcat runs with and the Tomcat administrator (if using a different
userid). No other users should have any access.
I am looking to encrypt it through configuration (not through any
code).I have reviewed the information provided in the link below,
which mentions configuration tips, but I don't understand some of
these (apart from the XML encoding).
https://cwiki.apache.org/confluence/display/TOMCAT/Password
The point of the article is that attempting to encrypt the Tomcat
configuration entries is … pointless. There will have to be a
decryption key saved somewhere that Tomcat has access to; if any
other users have access to that key, you’ve just wasted a lot of time
and effort for no gain. Much more efficient to expend that effort in
securing the Tomcat files.
I had this conversation with someone a long time ago and their argument
at the time was basically against shoulder-surfing. "If the password is
'hummingbird'" then someone can just read it and go write it down
elsewhere."
Okay, sure. So just make your password random junk and that will solve
the shoulder-surfing issue. All other use-cases are just making more
work for everybody who already really has access to the password.
I make it a habit of generating secrets basically like this:
$ dd if=/dev/urandom bs=1024 count=10 | sha1sum
10k of random garbage into sha1sum gives me a nice big random blob every
time. Copy, paste, done. Unless someone is able to take a photro over
your shoulder, you are fine. If that happens, why are you letting them
take pictures? Why are you letting them log into your application server
to impersonate your application? So many "whys".
Choosing a non-trivial password and file-level permissions should be
sufficient. Everything else is hand-waving.
I have become more interested in the ServiceBindingPropertySource class
recently, but that has MUCH more to do with deployment flexibility than
security. But the passwords aren't in server.xml anymore!
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
