logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <rgo...@apache.org>
Subject Re: Track passwords internally as char[] instead of String
Date Fri, 23 Aug 2013 04:47:48 GMT
The plugin would be similar to the secretkeyprovider in the flume Appender. In this case it
would decode the password.  The user would provide the actual decoder implementation so that
they can use any scheme they want for encoding/decoding.

Ralph

On Aug 22, 2013, at 9:26 PM, Gary Gregory <garydgregory@gmail.com> wrote:

> On Fri, Aug 23, 2013 at 12:10 AM, Ralph Goers <rgoers@apache.org> 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 <nicholas@nicholaswilliams.net>
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:nicholas@nicholaswilliams.net] 
>>>> 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 <nicholas@nicholaswilliams.net>
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 <garydgregory@gmail.com>
wrote:
>>>> On Mon, Aug 19, 2013 at 10:34 AM, Ralph Goers <rgoers@apache.org> 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 <garydgregory@gmail.com>
wrote:
>>>> 
>>>> On Mon, Aug 19, 2013 at 10:25 AM, Paul Benedict <pbenedict@apache.org>
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 <garydgregory@gmail.com>
wrote:
>>>> On Mon, Aug 19, 2013 at 7:27 AM, Ralph Goers <rgoers@apache.org> 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 <garydgregory@gmail.com>
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: garydgregory@gmail.com | ggregory@apache.org 
>>>> 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: garydgregory@gmail.com | ggregory@apache.org 
>>>> 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: garydgregory@gmail.com | ggregory@apache.org 
>>>> 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: garydgregory@gmail.com | ggregory@apache.org 
>>>> 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: garydgregory@gmail.com | ggregory@apache.org 
>>>> 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: garydgregory@gmail.com | ggregory@apache.org 
>>>> 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: garydgregory@gmail.com | ggregory@apache.org 
> 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

Mime
View raw message