Cryptomator: Passwords of closed vaults remain in RAM

Created on 7 Jan 2018  路  4Comments  路  Source: cryptomator/cryptomator

Hello, I'm using Windows 10 and I'm running Cryptomator in version: 1.3.3

I noticed that the passwords of Cryptomator are stored in the RAM even if the vault is closed.

Example: I start Cryptomator and open Vault1 and Vault2, work with them and close them. Then I open Vault3. Now, if you create a dump file of the RAM image of Cryptomator, you can still find the passwords for Vault1 and Vault2 although those are already closed. This could make it easier for malicious programs to get the passwords for the vaults.

Would it be possible to fix such 'leaks' or is this Java related and can't be fixed?
(The only possible way I found is restarting Cryptomator after closing a Vault before you open another one.)

question security-issue

Most helpful comment

This is in fact java related and can not be fixed easily. The usage of the JavaFX password field is the main reason for the password showing up in the memory dump. Because the creation of a memory dump requires elevated permissions an application which would be able to exploit this could do many other things which can not be prevented either.

All 4 comments

This is in fact java related and can not be fixed easily. The usage of the JavaFX password field is the main reason for the password showing up in the memory dump. Because the creation of a memory dump requires elevated permissions an application which would be able to exploit this could do many other things which can not be prevented either.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@cryptomator/libraries Is this still true? We changed with ef5eabdb799d5263fce78cc6adbf50660ac7cae7 the password field to be backed by a char array, which is swiped after unlock. Later we added the "showPassword" functionality, but a persistent String is only generated on user request.

We changed with ef5eabd the password field to be backed by a char array

Also related: f475f70

I guess this is the best we can do for now. Note that conversion to UTF-NFC still requires Strings, but at least we limit the use of Strings to the furthest point possible.

Was this page helpful?
0 / 5 - 0 ratings