Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8B2CE103EC for ; Thu, 22 Aug 2013 17:48:18 +0000 (UTC) Received: (qmail 67631 invoked by uid 500); 22 Aug 2013 17:48:18 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 67435 invoked by uid 500); 22 Aug 2013 17:48:18 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 67427 invoked by uid 99); 22 Aug 2013 17:48:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Aug 2013 17:48:17 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of garydgregory@gmail.com designates 209.85.214.48 as permitted sender) Received: from [209.85.214.48] (HELO mail-bk0-f48.google.com) (209.85.214.48) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Aug 2013 17:48:13 +0000 Received: by mail-bk0-f48.google.com with SMTP id my13so802161bkb.21 for ; Thu, 22 Aug 2013 10:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KvsZndwAS/KM3ebEhzbMyy1TrL6gQljDQHa0L3UGjcc=; b=vnCOmrIQIKCBXVIxBrKccwbhKNGe0+/388OsbIFu7Mn9hh+3S8SDM+/xHDlLsrVRil D2DjHyZgYshusz9R+nmHgq65eIyz30MHs6U1OOpGzCUtO3A+SPg8JX2UsxXqHLRjgLYI qztD6ERcRfQqDQX0GtXpwh5mVA1mH3ztjJOHK6hoXzGttYibnpcBTHhdP99FYSHmx8aI 4xuQ3OzWLW2bfCldoCGJE1/Ec8KYzkKeaP1yED4Dh+4qEao1W6ALj87REceab5CXG/gl aSFO0mTxvHXyiwwHNh22qBQlVmGTRe00gwPdbKNdlU5Qyhix5kZUJRF+WHP5p3zxN8F7 fE3w== MIME-Version: 1.0 X-Received: by 10.204.224.142 with SMTP id io14mr3379612bkb.27.1377193672099; Thu, 22 Aug 2013 10:47:52 -0700 (PDT) Received: by 10.205.6.7 with HTTP; Thu, 22 Aug 2013 10:47:51 -0700 (PDT) In-Reply-To: <8F116589-6322-47BE-ABEC-61292D269010@dslextreme.com> References: <424ED8AB-701B-4077-9FE0-9DDD7AC4FD4D@apache.org> <053BEBDD-A7B0-4B54-9A49-34ECB16F1E4F@apache.org> <62AC1DD9-393E-4FE9-A4AE-D523FE956687@nicholaswilliams.net> <55D7BBA0-EF76-482E-B125-A4208896231B@nicholaswilliams.net> <8F116589-6322-47BE-ABEC-61292D269010@dslextreme.com> Date: Thu, 22 Aug 2013 13:47:51 -0400 Message-ID: Subject: Re: Track passwords internally as char[] instead of String From: Gary Gregory To: Log4J Developers List Content-Type: multipart/alternative; boundary=485b3970cf549d03c204e48ce387 X-Virus-Checked: Checked by ClamAV on apache.org --485b3970cf549d03c204e48ce387 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 22, 2013 at 1: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. > Which feels like we are back to where we started, with my mention of http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords Gary > > 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 < > nicholas@nicholaswilliams.net> 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 < >> 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 wrote: >>> >>>> On Mon, Aug 19, 2013 at 10:34 AM, Ralph Goers 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 >>>>> wrote: >>>>> >>>>> On Mon, Aug 19, 2013 at 10:25 AM, Paul Benedict 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 >>>>> > wrote: >>>>>> >>>>>>> On Mon, Aug 19, 2013 at 7:27 AM, Ralph Goers 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 >>>>>>>> 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 > > > > -- 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 --485b3970cf549d03c204e48ce387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 22, 2013 at 1:26 PM, Ralph Goers <ralph.goers@dslextreme.= com> wrote:
A password that is in the xml configuration will be logged = to the status logger. It formats the arguments to the methods. =C2=A0You wo= uld need to annotate the attribute with something to get it to mask the val= ue.

Which feels like we are back to wher= e we started, with my mention of http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords=

Gary
=C2=A0

Ralph

On Aug 22, 2013, at 9:58 AM, Nick Williams wrote:

I think a more accurate sta= tement is "regardless of how passwords are stored (char[], String, etc= .), it's a Log4j design issue to ensure that they are never logged unde= r any circumstances." I think it's more important to be cognizant = of what you're doing with passwords and make sure they aren't expos= ed, no matter how they're represented.

Nick

On Aug 22, 2013, at 11:49 AM, Gar= y Gregory wrote:

On Thu, Aug 22, 2013 at 12:= 17 PM, Nick Williams <nicholas@nicholaswilliams.net> wrote:
I believe it's sufficient to simply *make sure* our code doe= sn't let these passwords from the configuration get into logs. I don= 9;t see it as necessary to add special password support, IMO. But I could b= e 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
<= br>
On Aug 22, 2013, at 6:28 AM, Gary Gregory wrote:

<= div class=3D"gmail_quote">On Mon, Aug 19, 2013 at 12:38 PM, Nick Williams <= span dir=3D"ltr"><nicholas@nicholaswilliams.net> wrote:
This discussion comes up on the Tomcat mailing list at least eve= ry few months, and it always ends the same way.

The passwords are in a configuration file. That configuratio= n 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 fi= le, it's because they've breached your firewall/server protection s= ystems 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 _fa= lse_ sense of security, which is more dangerous than no security at all.

My concern is more in the other dire= ction. 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 painstakingl= y 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 nev= er happen as the code stands now (do we have passwords in toString()s?)...<= br>
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.co= m> wrote:
On Mon, Aug 19, 2013 at = 10:34 AM, Ralph Goers <rgoers@apache.org> wrote:
I&= #39;m not sure how this applies to what you are suggesting, but we should a= void passwords being in clear text in the configuration. =C2=A0I would sugg= est 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/Howt= o/Secure_Passwords

So perhaps we need= a boolean password attribute on PluginElement and PluginAttribute

<= /div>
Gary
=C2=A0

Gary
=C2=A0

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:<= br>
Do you n= eed the password ever after authentication?

=
I guess it depends on whether the code handles re-auth in case of a di= sconnect.

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:
Wh= at passwords?

For example:

- org.apache.logging.l= og4j.core.net.SMTPManager.FactoryData.password
- org.apache.logging.log4= j.core.net.JMSTopicManager.password
- org.apache.logging.log4j.core.net.= JMSQueueManager.FactoryData.password

Gary
<= /font>



--
Cheers,
Paul



--



= --

<= /span>



--




--





--
--485b3970cf549d03c204e48ce387--