You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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 would much prefer file formats which are text based so that you can easily look into them (and maybe make a change directly).
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 User, i.e. remove all the key fields from the User class. The keys are already in the KeyStore. The getters in User can just delegate there.
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.
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 passwordCallback for that. All of that is already there, it just somehow got lost over the generations I think.
If we're lucky the entire User disappears then and we only have the KeyStore and the Config. :-)
Activity
[-]Private key is stored unencrypted[/-][+](Copy of) private key is stored unencrypted[/+]michaz commentedon Jun 15, 2024
It looks like different parts of the
Userclass disagree on what theKeyStoreis for.uwemaurer commentedon Jun 17, 2024
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 would much prefer file formats which are text based so that you can easily look into them (and maybe make a change directly).
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?
michaz commentedon Jun 17, 2024
About the keys, I think we can just stop storing them in the
User, i.e. remove all the key fields from theUserclass. The keys are already in theKeyStore. The getters inUsercan just delegate there.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
passwordCallbackfor that. All of that is already there, it just somehow got lost over the generations I think.If we're lucky the entire User disappears then and we only have the KeyStore and the Config. :-)
michaz commentedon Jun 17, 2024
I'll give it a try, with #16 because they kind of go together.