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 *[image: 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 <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 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 > >
![https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*](https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*){kind=link}