Encryption keys stored as plain text

Feature
1

It would make Syncthing more secure if it supports data-at-rest encryption. That is:

  1. *.pem certificates are decrypted on startup by user, then stored in RAM.
  2. Untrusted Devices encryption keys are hashed in <encryptionPassword>
2

Decrypting pem on startup only works if you never restart. We still sometimes crash, sometimes restart due to settings change, or due to an upgrade. Not being able to start up after that probably carries a higher risk to the users (things don’t get synced hence get lost) than having to roll a new device id due to a leaked pem.

Second point, I don’t have a strong opinion on. We use a key derivation function from the password, and we could derive the key from a hash assuming everyone hashes it the same (i.e., does not use a salt), so the only protection would be against users being silly and reusing passwords.

2 Likes
3

Yes, it might not be a good idea to add this as a default for all users. But for advanced users, it is worth adding for added security.

As for crashing and restarts, I think this can be solved by adapting the idea of SSH agent (or even use the agent directly).

4

And some of us restart constantly… I have some systems I restart on a regular basis so that syncthing doesn’t get confused due to me moving files around during the nightly/weekly cron jobs.

And then there are systems that have a periodic reboot scheduled.

All of it unmanned.

5

What we could do is use the secret stores available on systems that support that concept, at least macOS and Windows. Doing so would also require implementing support for export and import of the things in clear text, for backup and migration.

6

You can always change the password if you forgot it, so we could just hash it consistently

7

For encryption? We need to generate a key from something, currently it’s the password, using a KDF etc. If we store a hash instead, that just makes the hash the password, or I’m misunderstanding.

8

The thing we store in plain text but should not, IMHO, is the API key…

1 Like
9

The only reason we wouldn’t want to store a password in the config is if the user uses the same password for his gmail or whatever etc, and his config gets stolen. It’s ok that the hash becomes a password, if it gets stolen, its just a hash and not the password to his gmail.

3 Likes