Storing credentials safely about kapowarr HOT 9 OPEN

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.

from kapowarr.

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.

from kapowarr.

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.

from kapowarr.

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.

from kapowarr.

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

from kapowarr.

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

from kapowarr.

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

from kapowarr.

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?

from kapowarr.

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.

from kapowarr.