Have you looked at javax.security.auth.Destroyable?
On 3/26/19 9:07 AM, Finn Herpich wrote:
Hi Nicolas,
thanks for the long write up. I'm indeed working with a lot of C# in
the last year, but that is a pure accident, to reproduce the
SecureString-class was not my intention.
I'm totally aware of the problems you are listing, but sadly I've to
handle sensitive information which force me to reduce the attack
surface to a bare minimum for certain values. If an attacker has full
access to my process, as you said, it is game over; However I'm trying
to reduce the points in time where a value could get leaked to a
pagefile or whatever you can think of to be recovered later by memory
forensics and such. I know that I'm limit to how the OS handles
memory, memory access rights within the system, etc. and I've talked
to multiple penetration testers/security analysts in the past few weeks.
So coming from that requirement I did some tests with char arrays in
java which I at least could overwrite quickly enough to minimize the
points in time where it could be read and wasn't able to find any
traces left in memory (as you also mentioned with the .fill method).
However using OpenJFX controls I found my inputs multiple times in
memory afterwards, which lead me to the
com.sun.javafx.tk.quantum.GlassViewEventHandler class where the input
event is converted into a string and I somehow have the impression
that it would be some major work to get this out of the event flow for
a specialized control.
In the worst case I've to go back to C++, where it is hard to write
secure code, or Rust/Go which don't have such a wonderful and easy
deployable cross platform GUI like Java does with openjfx.
Cheers,
Finn
On 26.03.19 12:49, Nicolas Therrien wrote:
Hi Finn,
I assume you are coming from a C# background and looking for a
SecureString equivalent in Java. Check out this:
https://github.com/OWASP/passfault/blob/master/core/src/main/java/org/owasp/passfault/impl/SecureString.java
You could write your own javafx component with OWASP SecureString and
achieve the same result as in C#.
Hopefully this answers your question.
That being said, what you said about being faster than garbage
collection and again assuming you had SecureString in mind, makes me
think you might not really understand the purpose of SecureString in
C#. It does NOT guarantee that an attacker would not be able to see
the string if they had access to the application's runtime memory.
Think about it: if you can TYPE your password, there was a byte array
containing your clear text password before it was put in the
SecureString. And then if you can USE that password (during a
database connection), there was a byte array containing your clear
text password when you sent it to the driver. A simple breakpoint in
the right spot and a heap dump would reveal your password, always.
The reason is simple: your application does need to know the password!
The purpose of SecureString is not to protect from being able to
capture the password in memory or from heap dumps. The purpose is to
avoid the password from leaking in log files, console output or in
application messaging. By creating a separate String class extension
for it, the developers made sure that inadvertently calling
"toString()" (as a logger would do) would return some encrypted garbage.
SecureString is a simply a Safeguard against leaking sensitive
strings in logs, console output and application messaging.
If you are still concerned about someone inspecting the heap and look
for the short lived byte arrays containing what you typed, you can
always call .fill(0) on that byte array when you're done with it to
make it harder for the attacker. The OWASP class i shared with you
does that in the constructor. But again, if the attacker has access
to your process, all he has to do is set a breakpoint to the
SecureString constructor and voila, he can read the byte buffer
before its encrypted. Wiping only makes sure that the original byte
array could not inadvertently be the source of a leak later (ie
someone uses the byte array instead of the string)..That's the real
reason why the OWASP class is wiping the array.
Best regards,
*Nicolas Therrien*
Senior Software Developer
/https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png/
*o*: +1.819.931.2053
On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich <[email protected]
<mailto:[email protected]>> wrote:
Hi everyone,
I'll hope this is the right place to ask. I'm currently evaluating
multiple ways to write a cross platform application with the
requirement
to be able to clear certain inputs from memory rather quickly and
not
wait for the GCs mercy.
I've tracked the JavaFx TextInputControls back to the point where
the
character from the input event is transformed into a string. Which
happens roughly in com.sun.javafx.tk.quantum.GlassViewEventHandler.
My questions results in, if it would be possible to write a custom
control (or some other way) which would leave at least no traces
in the
string pool? Right now I've not enough knowledge about JavaFX
internals,
but it seems like this event handling is implemented way down the
rabbit
hole and it looks like a major afford to avoid the char->string
conversion?
I would be happy about any pointers where to look/start, or if a
project
like this would be doomed from the start =).
Cheers,
Finn
-- Alice and the Builders GmbH
Grantham-Allee 2-8, 53757 Sankt Augustin
Amtsgericht – Registergericht – Siegburg
HRB 13552, Sitz Siegburg
Geschäftsführer: Michael Sczepanski, Martin Hensel, Finn Herpich
