Ahhh. Okay, I see where the disconnect was, now. I think our best bet is a "boolean password() default false;" attribute on the @PluginAttribute annotation. This idea was mentioned earlier by someone else (I've lost track of who). The configuration processor should then log ten asterisks (**********) in place of the value for that attribute if it's given a value, or null/blank as it usually would if it's not given a value.
I think this is going to be more effective than using char[] instead of String, IMO. Thoughts? On Aug 22, 2013, at 12:26 PM, Ralph Goers wrote: > A password that is in the xml configuration will be logged to the status > logger. It formats the arguments to the methods. You would need to annotate > the attribute with something to get it to mask the value. > > Ralph > > On Aug 22, 2013, at 9:58 AM, Nick Williams wrote: > >> I think a more accurate statement is "regardless of how passwords are stored >> (char[], String, etc.), it's a Log4j design issue to ensure that they are >> never logged under any circumstances." I think it's more important to be >> cognizant of what you're doing with passwords and make sure they aren't >> exposed, no matter how they're represented. >> >> Nick >> >> On Aug 22, 2013, at 11:49 AM, Gary Gregory wrote: >> >>> On Thu, Aug 22, 2013 at 12:17 PM, Nick Williams >>> <[email protected]> wrote: >>> 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. >>> >>> It's something that is easy enough to do (String <-> char[]) so I want to >>> make sure that if we leave it as is, we're all OK saying "passwords are in >>> plain Strings and it's not a Log4j design issue" >>> >>> Gary >>> >>> >>> 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 >>> >>> >>> >>> >>> -- >>> 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 >> >
