Skip to content

(Copy of) private key is stored unencrypted #38

Open

Description

@michaz

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?

Activity

  1. changed the title [-]Private key is stored unencrypted[/-] [+](Copy of) private key is stored unencrypted[/+] on Jun 14, 2024
  2. michaz commented on Jun 15, 2024

    @michaz
    Author

    It looks like different parts of the User class disagree on what the KeyStore is for.

  3. uwemaurer commented on Jun 17, 2024

    @uwemaurer
    Collaborator

    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?

  4. michaz commented on Jun 17, 2024

    @michaz
    Author

    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. :-)

  5. michaz commented on Jun 17, 2024

    @michaz
    Author

    I'll give it a try, with #16 because they kind of go together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions