-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Copy of) private key is stored unencrypted #38
Comments
It looks like different parts of the |
My plan is to change the way the data is stored. I strongly dislike the Java serialized files, but it was like this when I took over the project and I didn't change it at the time. I think we can assume the local storage to be secure, the EBICS library needs to be able to restore the data from the files so even if we encrypt the data then the key needs to be stored somewhere locally too. Do you have any suggestions how to improve how the data is stored? |
About the keys, I think we can just stop storing them in the
Agreed. Yes, the encryption password for the keystore is in the config file anyway. That's why I was so surprised, because that means there's no reason to store the keys yet another time unencrypted. And if we don't find the password in the config, maybe because the user removed it, we can even ask them to type it in. There's already a If we're lucky the entire User disappears then and we only have the KeyStore and the Config. :-) |
I'll give it a try, with #16 because they kind of go together. |
Maybe that's intended because we consider local storage secure for purposes of this code.
But it may be surprising in some situations, since the code looks like it wants to use the
KeyStore
in the user directory, which is password-protected. So one might expect that once I remove my password from the config file, my secret key is safe. Or that when I delete the user directory, my secret key is gone.However, the secret key is also saved unencrypted in the "serialized User", which is not in the user directory, and the password doesn't seem to have any role at all?
The text was updated successfully, but these errors were encountered: