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.
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]] >> 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] >> 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 >
