Encrypt API tokens

[adriankumpf]

With this PR, API tokens are stored in encrypted form in the database.

During the database migration a randomly generated key will be used encrypt the tokens if no ENCRYPTION_KEY environment variable was provided.

If the application is started without the presence of an ENCRYPTION_KEY (or if the key failed to decrypt the existing tokens), the UI will display a warning with further instructions.

[Hypfer]

Please just ignore this comment if I missed something as I haven't used this software, but I can't but wonder if this is really the correct approach.

So if I understand it correctly, the issue here was that Grafana used the same db credentials as the data collection service, meaning that it also had access to the tokens stored in the db, right?
To prevent that from happening, this PR will encrypt the tokens stored in the DB with a secret that is only known to the data collection service provided via an env variable, yes?

What confuses me about is is:
Why not instead just use a different postgres user with different permissions for grafana, so that it can only see the collected data but not the configuration stored in the db?

I feel like I'm missing something here

[adriankumpf]

Please just ignore this comment if I missed something as I haven't used this software, but I can't but wonder if this is really the correct approach.

So if I understand it correctly, the issue here was that Grafana used the same db credentials as the data collection service, meaning that it also had access to the tokens stored in the db, right? To prevent that from happening, this PR will encrypt the tokens stored in the DB with a secret that is only known to the data collection service provided via an env variable, yes?

What confuses me about is is: Why not instead just use a different postgres user with different permissions for grafana, so that it can only see the collected data but not the configuration stored in the db?

I feel like I'm missing something here

Ultimately, this is a second layer of protection should someone manage to gain access to Grafana.

Another Postgres user that does not have access to the tokens table would work just as well. Just note that the upgrade path for existing users (and the setup for new ones) should be as simple as possible. I don't see that being the case with that approach. Whereas the encryption can be done automatically during the update.

[Hypfer]

Whereas the encryption can be done automatically during the update.

It does still require the user to edit the container config so that the secret gets stored though

[adriankumpf]

When starting the container after the update, the tokens will be encrypted with a random key (if no key was provided by the user). So you will still be logged in after the update even though the tokens are already encrypted.

A warning message displayed in the UI will then provide further instructions on how to proceed in this case. So even if you do not read the release notes and upgrade blindly, TeslaMate will continue to work after the update. Only after a restart you'll be required to log in again (if the container config has not been updated at that point).

[martinh2011]

And in postgresql backups the tokens will be encrypted, too. So even if somebody gets hold of a teslamate database backup, the encrypted token is useless. Not a very likely threat, though, but nice to have.

[parkr]

@adriankumpf Are there guidelines/best practices for generating an ENCRYPTION_KEY? I was going to add this to my config today but am not sure what is allowed in this field. Thanks!

[adriankumpf]

@adriankumpf Are there guidelines/best practices for generating an ENCRYPTION_KEY? I was going to add this to my config today but am not sure what is allowed in this field. Thanks!

In general, the same guidelines apply to the encryption key as to strong passwords:

• Long passwords are more secure
• Make your password unique

There are no limits on character length or characters allowed.

[parkr]

@adriankumpf Sounds good. I was mostly curious about allowed character sets, but it sounds like any bytes will do. Thanks!

[okamiokami]

As a non technically minded user (not to this level anyway) I find this extremely confusing.

Teslamate is working, which is the most important thing for me, but I keep getting the “create encryption key” notification.

I have close to zero experience with Docker and I blindly followed the install guide 1.5 years ago.

Now, I made a few tries and I got a copy of the yml file, but editing it (adding the encryption key taken form the logs, with the correct syntax from the guide) had no effect on the notification, which is still there. I am also on Postgres 13 and changing the Postgres bit in the yml setting resulted in downloading Postgres 14 and Teslamate not working anymore (which shows that I put the YML back in the right place, and confirms that just adding the encryption key had no effect). I stopped and started the container (and the NAS) a few times in between.

My question is: is there any easy (or completely guided) way to add the encryption key to settings?

Alternatively, what would happen if I backed up my current data, erased Teslamate completely and reinstall it?