Custom InputControl w/o char->string conversion
nicolas.therrien at motorolasolutions.com
Tue Mar 26 11:49:53 UTC 2019
I assume you are coming from a C# background and looking for a SecureString
equivalent in Java. Check out this:
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
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.
Senior Software Developer
On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich <finn at 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 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 =).
> 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
More information about the openjfx-dev