Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: Alternative for properties like javax.net.ssl.trustStorePassword ... Date: Wed, 8 Feb 2023 15:37:25 +0100 Organization: A noiseless patient Spider Lines: 54 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 8 Feb 2023 14:37:25 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="297522a9eec62b418f5e6ca34118f825"; logging-data="233981"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18YSInCziuHlRKexJ01PSN9" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Cancel-Lock: sha1:mI7eX/qx9N7NK+RXWSMFen0zSRg= Content-Language: en-US In-Reply-To: Xref: csiph.com comp.lang.java.programmer:39917 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 seems possibly relevant, too. -- DF.