If some java appliation is supposed to use a trustStore, then apparently
all hits on google for the obvious words will suggest to start the application with an option "-Djavax.net.ssl.trustStorePassword=..." passed to the java executable...

Assuming I do not want everyone on the machine to see the password in clear text in the "ps -ef" output, what would be "safer" alternatives?

The most obvious one might be to set the property from my own code, (after reading the pw from a file that not everyone on the machine has access to)
but my code comes too late: some beans already got initialized and didn't
see the property, before the program gets to set the properties. --
I'm not a master of beans... maybe I could just add another bean that
would do the "setProperty" as a sideeffect just in time before the other
bean needs the property... haven't thought this through, yet.

Maybe I'm still in the stone-age, and there is already some new property that would allow me to just specify another file holding the relevant passwords,
or something else?

Any ideas? Is passing a password as argument to a process nothing to worry about?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Any ideas? Is passing a password as argument to a process nothing to worry about?

first result https://docs.oracle.com/javadb/10.8.3.0/adminguide/cadminsslclient.html shows setting the password as system property right before making your first database connection.
How and when are you making your database connection?
I normally make database connections using datasource in the tomcat config files with the password in the config as an encrypted string and reference a decryption jar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/26/2023 1:59 PM, Andreas Leitgeb wrote:

If some java appliation is supposed to use a trustStore, then apparently
all hits on google for the obvious words will suggest to start the application
with an option "-Djavax.net.ssl.trustStorePassword=..." passed to the java executable...

Assuming I do not want everyone on the machine to see the password in clear text in the "ps -ef" output, what would be "safer" alternatives?

The most obvious one might be to set the property from my own code, (after reading the pw from a file that not everyone on the machine has access to) but my code comes too late: some beans already got initialized and didn't
see the property, before the program gets to set the properties. --
I'm not a master of beans... maybe I could just add another bean that
would do the "setProperty" as a sideeffect just in time before the other
bean needs the property... haven't thought this through, yet.

Maybe I'm still in the stone-age, and there is already some new property that would allow me to just specify another file holding the relevant passwords, or something else?

Any ideas? Is passing a password as argument to a process nothing to worry about?

A password in visible plain text is at least a potential problem.

But there are no miracles.

You have some code that are not yours that use this property.

Your regular code that runs later cannot change that property when needed.

You need to get some code to run before the code using this property.

Startup servlet may be too unreliable timing wise.

Some googling indicate that a ServletContextListener and doing
it in contextInitialized may be better.

If everything is using Spring you may be able to sneak some
code in via Spring early enough.

If they will allow you to use sledgehammer then a Java agent
will run before anything!

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

e.d.pro...@gmail.com <e.d.programmer@gmail.com> wrote:

Any ideas? Is passing a password as argument to a process nothing to worry >> about?

first result https://docs.oracle.com/javadb/10.8.3.0/adminguide/cadminsslclient.html
shows setting the password as system property right before making
your first database connection. How and when are you making your
database connection?

It is a web-application running in tomcat, and tomcat itself is
currently configured in "bin/setenv.sh" to start with those "-D..."
options, setting key- & truststore file and their password.

I normally make database connections using datasource in the tomcat
config files with the password in the config as an encrypted string
and reference a decryption jar.

That sounds like a promising solution...
Could I set them e.g. in the server.xml ?

The tomcat-config is already readable only by the user running it,
which would be a huge advantage to current state where the password
shows up in process list visible even for other users.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Arne Vajhøj <arne@vajhoej.dk> wrote:

On 1/26/2023 1:59 PM, Andreas Leitgeb wrote:

Any ideas? Is passing a password as argument to a process nothing to worry >> about?

A password in visible plain text is at least a potential problem.

You have some code that are not yours that use this property.
Your regular code that runs later cannot change that property when needed. You need to get some code to run before the code using this property.
Startup servlet may be too unreliable timing wise.
Some googling indicate that a ServletContextListener and doing
it in contextInitialized may be better.

Actually, my hope was, that I wouldn't really need any own code for
that at all.

Alternatives could in principle be:
- newer properties with an extra level of indirection for the sensible
data, ideally understood by the same (java crypto internal) code
that currently reads these "indiscrete" properties...
I didn't find any from googling, but that doesn't necessarily mean
that there couldn't be any.
- Given that my app runs in tomcat, maybe tomcat already has a way to
specify properties in its configuration (outside setenv.sh)...
(I didn't think of that until e.d.programmer mentioned tomcat config
in his followup. I'm not sure if he meant it that way: as defining
properties somewhere inside e.g. the xmls or some property-files that
would be read by tomcat after startup)
- maybe others...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

That sounds like a promising solution...
Could I set them e.g. in the server.xml ?

I'm not an expert on what server.xml can do but database config that I've seen is normally in context.xml. Just paste the encrypted string in a resource tag, use a factory to reference the decryption method, and drop your jdbc jar and decryption jar in
the tomcat lib folder.
https://stackoverflow.com/a/48179892

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/01/2023 19:59, Andreas Leitgeb wrote:

If some java appliation is supposed to use a trustStore, then apparently
all hits on google for the obvious words will suggest to start the application
with an option "-Djavax.net.ssl.trustStorePassword=..." passed to the java executable...

Assuming I do not want everyone on the machine to see the password in clear text in the "ps -ef" output, what would be "safer" alternatives?

The most obvious one might be to set the property from my own code, (after reading the pw from a file that not everyone on the machine has access to) but my code comes too late: some beans already got initialized and didn't
see the property, before the program gets to set the properties. --
I'm not a master of beans... maybe I could just add another bean that
would do the "setProperty" as a sideeffect just in time before the other
bean needs the property... haven't thought this through, yet.

Maybe I'm still in the stone-age, and there is already some new property that would allow me to just specify another file holding the relevant passwords, or something else?

Any ideas? Is passing a password as argument to a process nothing to worry about?

A password in the clear, stored somewhere on disk, is always something
to worry about.

But I think the only way to solve the conundrum is to leverage the OS
and, more precisely, its user management.

Make the truststore file readable to the Tomcat user (and su) only. Then
you could perhaps even dispense with a password on the TS (although it'd probably better not to).

Or leverage some kind of secure storage that's freely accessible to the
user, but to the user only, to retrieve the password (be it a mere file
or a cryptographically-secured safe).

I don't know of any other way. There might be some. I somewhat doubt it. Security is easy once you're in it. Bootstrapping it, is a can of worms.

The tomcat-config is already readable only by the user running it,
which would be a huge advantage to current state where the password
shows up in process list visible even for other users.

Well, there you go.

This
<https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/>
seems possibly relevant, too.

--
DF.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)