Custom InputControl w/o char->string conversion
david.grieve at oracle.com
Tue Mar 26 13:35:08 UTC 2019
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.
> 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:
>> 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
>> *o*: +1.819.931.2053
>> On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich <finn at thebuilders.de
>> <mailto: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
>> to be able to clear certain inputs from memory rather quickly and
>> wait for the GCs mercy.
>> I've tracked the JavaFx TextInputControls back to the point where
>> 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
>> but it seems like this event handling is implemented way down the
>> hole and it looks like a major afford to avoid the char->string
>> I would be happy about any pointers where to look/start, or if a
>> 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