Storing credentials safely

[Casvt]

Is your feature request related to a problem? Please describe.

Currently, the credentials of services are stored in raw unencrypted format inside the database. That's not very safe...

Describe the solution you'd like

For the credentials to be stored in encrypted form inside the database.

Additional context

The whole problem is that I don't know how to implement this. The reason being that Kapowarr needs to have access to the raw credentials at any moment. This means that if the credentials were to be stored in encrypted form inside the database, Kapowarr will need to be able to decrypt the data at any point in time, without user input (like the user giving a password). If Kapowarr can decrypt data at any point in time without user input, so can any other person that has access to the database file. And thus we have this problem to which I don't know the solution.

[majora2007]

You can generate a key on startup of your application which will be used to encrypt your user/password. The key can be stored outside the database on the user's machine and read into memory at startup.

Then you can decrypt the username/password. This is a very simple solution, unless you want to use an external library that might offer more realistic implementation strategies.

[Casvt]

So basically: "Encrypt it with a key and put the key somewhere on the system, outside the database"? That doesn't solve the problem. The project is open source so everyone can simply figure out where the key would be stored and when "stealing" the database, also grab the key and use it to still get access to the raw credentials. It's basically no better than storing the key in a variable inside the code.

[majora2007]

Generate it per user on their machine based on machine info. I do this for my codebase for JWT encryption (not credentials).

Yes, if you have access to the users machine, then you'd be compromised. You could do some hardware based key to generate a unique encryption key, but then you wouldn't be able to move from one instance to another. Likewise with docker could hit some roadblocks.

Just wanted to throw some suggestions out, I'm honestly not sure how to solve with a home grown solution.

[ajurna]

I think in a professional env I would put it in azure key vault or similar. usually the recommendation is store them in a config file or the env variables rather than a DB.

Encrypting them does no use if the weak point if the front end. if I can bypass auth and get the settings API to load then it doesn't matter what encryption you use it will be decrypted for me.

[majora2007]

I would recommend to just look at what was done in sonarr and model after that. Open source has a lot of limitations as all code is visible, so if you want to add extra security, you have to put more onus onto the user when setting up the application (like setting env variables, etc).

[RationalAnarchist]

As I understand it, for Mega at least, you need to send the username and password over in encrypted form (base64?). So what I'd do is store the username and the encrypted string. The application has what it needs to get the data and if someone gets hold of the db, they can still use it to access the mega account but nothing else (the big risk of plaintext passwords is where passwords are reused).

[opicron]

Generate a key on install, and salt the passwords before encrypting. Decrypt the values from env/db when required.

https://github.com/tasos-py/AES-Encryption-Classes/blob/master/aes_encryption.py

[Casvt]

So:

1. Generate a key
2. Use it to encrypt the data and store it
3. Use it to decrypt the stored data for usage in code

The problem then is that everyone that has access to the database file can also just grab the key to decrypt everything. It's like having a lock, but with the key hanging next to it; does the lock really work then?

[opicron]

I think the key has to be at another point than the database at least. But yes, you are right-- for example Wordpress handles it the exact same way.