On Fri, Aug 23, 2013 at 12:10 AM, Ralph Goers <[email protected]> wrote:
> I worked in an environment like Kurt's. passwords simply were not allowed > in clear text in config files. I still think a plugin is the right way to > handle that. > What would the plugin do? Gary > > Ralph > > On Aug 22, 2013, at 11:55 AM, Nick Williams <[email protected]> > wrote: > > This is what file permissions are for. The file should be protected so > that only those who are authorized may view it. For example, on a Linux > machine it may be 0400 where the user is the account that the application > runs under. Then only the application and root can view the file. > > N > > On Aug 22, 2013, at 1:32 PM, Kurt Lehrke wrote: > > I believe there’s a small oversight in the idea that if someone has access > to your box, that it’s game over.**** > ** ** > Think about a situation where a company may have a box with administrators > and users. They may still want levels of security. For example, say you > have a JDBCAppender that has a user name and password in their log4j2 > configuration. The administrator may have access to their application and > the database, but a user may only need access to the box. Therefore, > having the user name and password hashed in the configuration file would > ensure that a user (non admin) on the system can’t get to the database. > This is an interesting challenge since the password hash would have to be a > symmetric algorithm. It’s still merely only a light level of security > since anyone with bad intent could still figure out the decryption by > looking at the encryption algorithm.**** > ** ** > In my experience (supply chain development), some companies are pretty > strict on having any password left in plain text, even if it is just for > logging.**** > ** ** > Just a thought.**** > ** ** > Thanks,**** > Kurt**** > ** ** > ** ** > *From:* Nick Williams > [mailto:[email protected]<[email protected]> > ] > *Sent:* Thursday, August 22, 2013 11:18 AM > *To:* Log4J Developers List > *Subject:* Re: Track passwords internally as char[] instead of String**** > ** ** > 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] <[email protected]> > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory**** > > > > > --**** > E-Mail: [email protected] | [email protected] <[email protected]> > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory**** > > > **** > --**** > Cheers, > Paul**** > > > > > --**** > E-Mail: [email protected] | [email protected] <[email protected]> > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory**** > > > > > --**** > E-Mail: [email protected] | [email protected] <[email protected]> > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory**** > > > > > --**** > E-Mail: [email protected] | [email protected] <[email protected]> > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory**** > ** ** > > > > > --**** > E-Mail: [email protected] | [email protected] <[email protected]> > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > 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<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
