You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2018/09/07 17:25:11 UTC
Re: [External] How to wipe out passwords and keys
Well, there are a few things that can be done to mitigate some of it.
On the “transport” side like HTTP, use authentication mechanisms that don’t even send the password. Use certs or use Digest auth or similar. This can be setup so CXF doesn’t even see the password on the server side. Client side is a bit different as the specs (JAX-WS/JAX-RS, et…) more or less require them to be String, but you could possibly configure the JVM level authenticator and again bypass CXF entirely.
For passwords within payloads, there is really not much at all that can be done. We generally use an StAX XMLStreamReader. The only way to get attribute values is via a String. Thus, if there is a password as an attribute, it’s a String. For textual element data, there are methods to get as char[], but I do not know if JAXB would use those. That’s down in JAXB. There are ways to convince JAXB to not use a String in the objects it serializes/deserializes (via XmlAdapters), so it MAY be possible to keep the Strings for a very short time and hope they get garbage collected. But that’s for stuff in the raw payload and only for cases where we can fully stream. For stuff in places like SOAP headers or if we need to stop streaming, there is a possibility that they stored as nodes in a DOM or similar. The only way to create a Text node in a DOM is via a String.
Anyway, it’s a very complex question.
Dan
> On Sep 5, 2018, at 6:32 PM, Andriy Redko <dr...@gmail.com> wrote:
>
> Hi Navaneet,
>
> Got it, I think it may not be solvable on CXF side. There are many layer in between, f.e. JAXB parsers.
> Probably the simplest solution would be to not store passwords in clean text in XML but rather use encyption.
> In this case you would have the extact place in the code to decrypt the password and clean up the buffers right
> after. Not sure if it is possible in your case. Thanks.
>
> Best Regards,
> Andriy Redko
>
> KN> Hi Andriy:
>
> KN> Thanks for the quick response.
>
> KN> OWASP has general ideas about storing the password and that is where this requirements on wiping out password comes
> KN> from, but my question was specific to Apache CXF and XML Schema:
>
> KN> How do I get Apache CXF to work in a way that the framework never uses Java String, an immutable object whose
> KN> memory cannot be accessed by the client, to marshall/unmarshall passwords and other secrets?
>
> KN>
>
> KN> Nav
>
> KN>
>
> KN> Sent from Mail for Windows 10
>
> KN>
>
>
>
> KN> From: Andriy Redko <dr...@gmail.com>
> KN> Sent: Tuesday, September 4, 2018 7:45:35 PM
> KN> To: Kumar, Navaneet; dev@cxf.apache.org
> KN> Subject: [External] Re: How to wipe out passwords and keys
> KN> Hi Navaneet,
>
> KN> The OWASP has a dedicated page related to storing password securily:
> KN> https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet. Is it helpful? Thank you.
>
> KN> Best Regards,
> KN> Andriy Redko
>
> KN> Tuesday, September 4, 2018, 10:47:56 AM, you wrote:
>
> KN>> We have a security requirement where we must not leave passwords and other secrets in memory for long. We must
> KN>> “wipe-out” such secrets in memory as soon as we are done with using them.
> KN>> Passwords are currently modeled as an “xsd:string” in our system resulting in a Java String class to manipulate them.
> KN>> Java String is immutable in that there is no way to write spaces or other characters to the memory used by this object after we are done with it.
>
> KN>> I don’t see a way to use say a character array to bind passwords.
>
> KN>> Has anyone else come across this issue? What is the recommended approach?
>
> KN>> Thanks
>
>
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
RE: [External] How to wipe out passwords and keys
Posted by "Kumar, Navaneet" <Na...@Honeywell.com>.
Thanks Dan for you detailed reply.
Yes. It is almost impossible to handle passwords correctly. May be the xsd spec itself needs to change with a different xsd type for secrets.
We are giving up on this for now, accepting the risk.
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Friday, September 7, 2018 1:25 PM
To: dev@cxf.apache.org
Cc: Kumar, Navaneet <Na...@Honeywell.com>
Subject: Re: [External] How to wipe out passwords and keys
Well, there are a few things that can be done to mitigate some of it.
On the “transport” side like HTTP, use authentication mechanisms that don’t even send the password. Use certs or use Digest auth or similar. This can be setup so CXF doesn’t even see the password on the server side. Client side is a bit different as the specs (JAX-WS/JAX-RS, et…) more or less require them to be String, but you could possibly configure the JVM level authenticator and again bypass CXF entirely.
For passwords within payloads, there is really not much at all that can be done. We generally use an StAX XMLStreamReader. The only way to get attribute values is via a String. Thus, if there is a password as an attribute, it’s a String. For textual element data, there are methods to get as char[], but I do not know if JAXB would use those. That’s down in JAXB. There are ways to convince JAXB to not use a String in the objects it serializes/deserializes (via XmlAdapters), so it MAY be possible to keep the Strings for a very short time and hope they get garbage collected. But that’s for stuff in the raw payload and only for cases where we can fully stream. For stuff in places like SOAP headers or if we need to stop streaming, there is a possibility that they stored as nodes in a DOM or similar. The only way to create a Text node in a DOM is via a String.
Anyway, it’s a very complex question.
Dan
On Sep 5, 2018, at 6:32 PM, Andriy Redko <dr...@gmail.com>> wrote:
Hi Navaneet,
Got it, I think it may not be solvable on CXF side. There are many layer in between, f.e. JAXB parsers.
Probably the simplest solution would be to not store passwords in clean text in XML but rather use encyption.
In this case you would have the extact place in the code to decrypt the password and clean up the buffers right
after. Not sure if it is possible in your case. Thanks.
Best Regards,
Andriy Redko
KN> Hi Andriy:
KN> Thanks for the quick response.
KN> OWASP has general ideas about storing the password and that is where this requirements on wiping out password comes
KN> from, but my question was specific to Apache CXF and XML Schema:
KN> How do I get Apache CXF to work in a way that the framework never uses Java String, an immutable object whose
KN> memory cannot be accessed by the client, to marshall/unmarshall passwords and other secrets?
KN>
KN> Nav
KN>
KN> Sent from Mail for Windows 10
KN>
KN> From: Andriy Redko <dr...@gmail.com>>
KN> Sent: Tuesday, September 4, 2018 7:45:35 PM
KN> To: Kumar, Navaneet; dev@cxf.apache.org<ma...@cxf.apache.org>
KN> Subject: [External] Re: How to wipe out passwords and keys
KN> Hi Navaneet,
KN> The OWASP has a dedicated page related to storing password securily:
KN> https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet. Is it helpful? Thank you.
KN> Best Regards,
KN> Andriy Redko
KN> Tuesday, September 4, 2018, 10:47:56 AM, you wrote:
KN>> We have a security requirement where we must not leave passwords and other secrets in memory for long. We must
KN>> “wipe-out” such secrets in memory as soon as we are done with using them.
KN>> Passwords are currently modeled as an “xsd:string” in our system resulting in a Java String class to manipulate them.
KN>> Java String is immutable in that there is no way to write spaces or other characters to the memory used by this object after we are done with it.
KN>> I don’t see a way to use say a character array to bind passwords.
KN>> Has anyone else come across this issue? What is the recommended approach?
KN>> Thanks
--
Daniel Kulp
dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://talend.com<http://coders.talend.com>