Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #39917
| From | Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Alternative for properties like javax.net.ssl.trustStorePassword ... |
| Date | 2023-02-08 15:37 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <ts0c35$74ft$1@dont-email.me> (permalink) |
| References | <slrntt5jd0.pa7s.avl@logic.at> |
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.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread
Alternative for properties like javax.net.ssl.trustStorePassword ... Andreas Leitgeb <avl@logic.at> - 2023-01-26 18:59 +0000
Re: Alternative for properties like javax.net.ssl.trustStorePassword ... "e.d.pro...@gmail.com" <e.d.programmer@gmail.com> - 2023-01-26 12:50 -0800
Re: Alternative for properties like javax.net.ssl.trustStorePassword ... Andreas Leitgeb <avl@logic.at> - 2023-01-31 23:30 +0000
Re: Alternative for properties like javax.net.ssl.trustStorePassword ... "e.d.pro...@gmail.com" <e.d.programmer@gmail.com> - 2023-02-01 04:25 -0800
Re: Alternative for properties like javax.net.ssl.trustStorePassword ... Arne Vajhøj <arne@vajhoej.dk> - 2023-01-26 16:50 -0500
Re: Alternative for properties like javax.net.ssl.trustStorePassword ... Andreas Leitgeb <avl@logic.at> - 2023-01-31 23:51 +0000
Re: Alternative for properties like javax.net.ssl.trustStorePassword ... Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2023-02-08 15:37 +0100
csiph-web