Skip to content
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

Key metadata is stored unencrypted #2128

Open
nioncode opened this issue Dec 28, 2018 · 8 comments

Comments

@nioncode
Copy link

commented Dec 28, 2018

Output of restic version

restic 0.9.2 compiled with go1.11 on linux/amd64

How did you run restic exactly?

restic -r /repo init

What backend/server/service did you use to store the repository?

local

Expected behavior

Keys should contain no plaintext information (apart from salt, iteration, ...).

Actual behavior

Keys contain host name, username, and time of creation in plaintext.

Do you have any idea what may have caused this?

Restic stores key metadata unencrypted.

Do you have an idea how to solve the issue?

Store key metadata encrypted. We could update the key format by adding e.g. a hostname_enc field and blanking the hostname field for new repos. Then old clients would show empty metadata until they are updated. We should also migrate existing keys to remove potentially old plaintext metadata from existing repos.

@fd0

This comment has been minimized.

Copy link
Member

commented Dec 31, 2018

We'll probably just remove the fields from the key metadata, that should be sufficient.

@fd0 fd0 added the feature request label Dec 31, 2018

@nioncode

This comment has been minimized.

Copy link
Author

commented Dec 31, 2018

How are keys identified then, if all their metadata gets removed? Or do you just want to remove the plaintext fields and introduce encrypted ones?

@fd0

This comment has been minimized.

Copy link
Member

commented Jan 1, 2019

Keys only need an ID for deletion, and the key ID is the name of the key file in the repo, which depends on the content but is not contained in the metadata within the file.

I was suggesting to just remove the fields, without introducing encrypted counterparts. I doubt that the data there is really used by anybody.

@mholt

This comment has been minimized.

Copy link
Contributor

commented Jan 2, 2019

Would the current key that was used to access the repository still be indicated? Otherwise I think there'd be absolutely no way to know which key to delete.

@fd0

This comment has been minimized.

Copy link
Member

commented Jan 6, 2019

Yes, through the key ID (the filename prefix).

@cdhowie

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2019

Perhaps have this be optional. We use a key per backup host and it's nice to be able to quickly see which key belongs to which host. Without this data in restic, we'd have to maintain the data somewhere else (company wiki, for example) -- not the worst thing, but why fix what isn't broken?

Edit: Though, if the metadata is encrypted with the repository master key, you'd still be able to see all key metadata by supplying a correct password. I'd be more likely to support that change than removing the metadata altogether.

@nioncode

This comment has been minimized.

Copy link
Author

commented Jan 6, 2019

I agree that it's nice to have, but this leaks metadata unencrypted. That's why I proposed to have them stored encrypted, so that each key that can decrypt the repo can still read all metadata like it is now, but the not trusted backup location can not gather the metadata in plaintext. This way, there would be no user facing changes at all.

@cdhowie

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2019

there would be no user facing changes at all.

That depends if the repository is automatically migrated to store the data encrypted. If so, the key IDs will necessarily change and, depending on syncing processes/restrictions, the user may need to be aware that this happened.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.