And if you want the user to have this capability, they will also have the power to muck with the encrypted password so that logging stops, or to create loggers all set to TRACE so that your database creates hundreds of gigabytes of logging data in just a few days.
My point being, if you trust them enough to manipulate your logging configuration responsibly, you better also be able to trust them with the password to your logging database. Encrypted or not, I would never permit access to a configuration file to a user that I didn't trust with system passwords. Nick On Aug 22, 2013, at 2:07 PM, Kurt Lehrke wrote: > Sure that’s ideal, but what if you still want the user to have access to the > configuration file for say adding custom loggers. You still may not want > them to have the information for direct access to the database. My only > point is that the flexibility would be nice. > > Thanks, > Kurt > > From: Nick Williams [mailto:[email protected]] > Sent: Thursday, August 22, 2013 1:55 PM > To: Log4J Developers List > Subject: Re: Track passwords internally as char[] instead of String > > 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 > >
