I believe it's sufficient to simply *make sure* our code doesn't let these passwords from the configuration get into logs. I don't see it as necessary to add special password support, IMO. But I could be missing something.
N On Aug 22, 2013, at 6:28 AM, Gary Gregory wrote: > On Mon, Aug 19, 2013 at 12:38 PM, Nick Williams > <[email protected]> wrote: > This discussion comes up on the Tomcat mailing list at least every few > months, and it always ends the same way. > > The passwords are in a configuration file. That configuration file lives with > the application. So, for example, if the application is a web app the > configuration file lives on the web app server or a server it has access to. > Either way, if a hacker gets a hold of that configuration file, it's because > they've breached your firewall/server protection systems and it's game over > anyway. > > There's really no use in making efforts to protect passwords in these > configuration files. Any effort to do so just adds a _false_ sense of > security, which is more dangerous than no security at all. > > My concern is more in the other direction. When secrets are in String > objects, they end up as plain text in log files or any kind of dump (if > Strings are dumped with toString()). At work, we get different kinds of logs > from users where the user has painstakingly blanked out certain data. Using > char[] avoids saying giving in plain text your secrets when they are in > Strings. In the case of Log4j2, this may never happen as the code stands now > (do we have passwords in toString()s?)... > > Gary > > > Nick > > On Aug 19, 2013, at 9:54 AM, Gary Gregory wrote: > >> On Mon, Aug 19, 2013 at 10:52 AM, Gary Gregory <[email protected]> >> wrote: >> On Mon, Aug 19, 2013 at 10:34 AM, Ralph Goers <[email protected]> wrote: >> I'm not sure how this applies to what you are suggesting, but we should >> avoid passwords being in clear text in the configuration. I would suggest >> using a standard plugin interface similar to what I did with the secret key >> provider in the Flume Appender. >> >> We should at the last offer something like >> http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords >> >> So perhaps we need a boolean password attribute on PluginElement and >> PluginAttribute >> >> Gary >> >> >> Gary >> >> >> Ralph >> >> On Aug 19, 2013, at 7:29 AM, Gary Gregory <[email protected]> wrote: >> >>> On Mon, Aug 19, 2013 at 10:25 AM, Paul Benedict <[email protected]> >>> wrote: >>> Do you need the password ever after authentication? >>> >>> I guess it depends on whether the code handles re-auth in case of a >>> disconnect. >>> >>> Gary >>> >>> >>> >>> On Mon, Aug 19, 2013 at 8:55 AM, Gary Gregory <[email protected]> >>> wrote: >>> On Mon, Aug 19, 2013 at 7:27 AM, Ralph Goers <[email protected]> wrote: >>> What passwords? >>> >>> For example: >>> >>> - org.apache.logging.log4j.core.net.SMTPManager.FactoryData.password >>> - org.apache.logging.log4j.core.net.JMSTopicManager.password >>> - org.apache.logging.log4j.core.net.JMSQueueManager.FactoryData.password >>> >>> Gary >>> >>> Ralph >>> >>> On Aug 19, 2013, at 4:22 AM, Gary Gregory <[email protected]> wrote: >>> >>>> I've seen it done many places: Should we track passwords internally as >>>> char[] instead of String for ivars. >>>> >>>> This prevents Log4j spilling your secrets by accident in a toString to >>>> internal log call. >>>> >>>> Gary >>>> >>>> -- >>>> E-Mail: [email protected] | [email protected] >>>> Java Persistence with Hibernate, Second Edition >>>> JUnit in Action, Second Edition >>>> Spring Batch in Action >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> -- >>> Cheers, >>> Paul >>> >>> >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second Edition >> JUnit in Action, Second Edition >> Spring Batch in Action >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second Edition >> JUnit in Action, Second Edition >> Spring Batch in Action >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory > > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
