Custom InputControl w/o char->string conversion

[David Grieve]

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 <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
>>     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
>>
>
>