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 <mailto:f...@thebuilders.de>> 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
